Какая из баз данных NoSQL может предоставить поток *изменений* в набор результатов запроса?

Какая из баз данных NoSQL может предоставить поток изменений в набор результатов запроса?

Может ли кто-нибудь указать мне на несколько примеров?

Во-первых, я считаю, что ни одна из баз данных SQL не предоставляет эту функциональность - я прав?

Мне нужно иметь возможность указывать произвольные простые запросы, эквивалент которых в SQL может быть написан:

SELECT * FROM accounts WHERE balance < 0 and balance > -1000;

Я хочу начальный набор результатов:

id: 100, name: Fred, balance: -10
id: 103, name: Mary, balance: -200

но затем я хочу, чтобы поток изменений следовал вечно, пока я их не остановлю:

meta: remove, id: 100
meta: add,    id: 104, name: Alice, balance: -300
meta: remove, id: 103
meta: modify, id: 104, name: Alice, balance: -400
meta: modify, id: 104, name: Alison, balance: -400
meta: add,    id: 101, name: Clive, balance: -200
meta: modify, id: 104, name: Alison, balance: -100
...

Примечание. Я не говорю о потоковой передаче больших наборов результатов. Я ищу мягкий поток изменений в реальном времени.

Кроме того, его необходимо масштабировать, если это возможно.

Спасибо,

Крис.


person fadedbee    schedule 10.03.2011    source источник
comment
Примечание. Этот вопрос на самом деле представляет собой комплексную проверку перед добавлением такой функции в barricane-db (github.com/chrisdew/ баррикейн-дб). Нет смысла изобретать велосипед.   -  person fadedbee    schedule 10.03.2011


Ответы (8)


Хотя ответ был принят, есть еще один ответ, который затрагивает суть предположений, лежащих в основе вашего вопроса.

Какую коммерческую проблему вы связаны с получением списка изменений данных? Что, если бы вместо простого получения списка изменений данных вы получили набор событий, сообщающих вам, почему и как изменились данные.

Эта концепция является одной из фундаментальных причин CQRS как архитектуры. В основном вы сохраняете все события, которые вызвали изменение ваших данных, например. FundsDeposited, FundsWithdrawn и т. д., и вы получаете возможность «воспроизвести» эти события и узнать не только, как ваши данные изменились с течением времени, но и почему.

Как только вы пойдете по этому пути, вы получите возможность хранить события в виде потока, и вы больше не ограничены небольшой горсткой механизмов хранения. Вместо этого вы можете буквально использовать любой механизм хранения, и он выполнит свою работу.

person Jonathan Oliver    schedule 10.03.2011
comment
Это был бы мой ответ, и он отличный. Это также является целью [Prevayler][1] и [Madeleine][2]. Все изменения в базе данных создаются как объекты транзакций, и каждое изменение проходит через систему, изменяя состояние мира. [1]: prevayler.org [2]: madeleine.rubyforge.org - person François Beausoleil; 10.03.2011
comment
Да, это хороший момент. Я очень хорошо знаком с Prevaylor: github.com/chrisdew/barricane-db /blob/master/README.md - person fadedbee; 12.03.2011

CouchDB имеет ленту изменений. По сути, это цепочка блоков или история всех изменений в базе данных с момента создания. Вы можете получать поток через JSON, JSONP, длинный опрос или в виде непрерывного потока и писать приложения, которые реагируют на изменения в базе данных.

Вот лента изменений из моего блога

Чтобы узнать больше, ознакомьтесь с этим разделом руководства по CouchDB.

person Max Ogden    schedule 10.03.2011
comment
Спасибо, но я в замешательстве. Доступны ли изменения в представлениях или только все изменения? - person fadedbee; 10.03.2011
comment
Команда CouchDB работала над этим. Я считаю, что Бенуа, возможно, даже реализовал это в своей ветке. С текущим CouchDB единственный способ — просмотреть отфильтрованный канал изменений, а фильтр показывает только изменения, которые могут повлиять на представление (например, он вызывает тот же код, что и map-reduce). Когда вы получаете обновление _changes, вы пингуете URL-адрес просмотра. - person JasonSmith; 10.03.2011

Не уверен, что это именно то, что вы ищете, но подумал, что это, возможно, достаточно актуально, чтобы оправдать упоминание!

Если вы используете репликацию в MongoDB, все операции записи сохраняются в оплоге (журнале операций). Таким образом, каждая вставка/обновление/удаление записывается там, чтобы их можно было воспроизвести на вторичных узлах. Это ограниченная коллекция, поэтому циклически повторяется и перезаписывается (вы можете установить ее размер). Но теоретически этот оплог можно использовать как способ получить поток изменений — я сам не пробовал, но, возможно, вы могли бы опросить этот оплог.

person AdaTheDev    schedule 10.03.2011
comment
Спасибо, это половина пути, но это не то чистое интегрированное решение, которое я ищу. - person fadedbee; 10.03.2011

Только ответ мозгового штурма:

Возьмем, к примеру, MongoDB и не хотим получать доступ к ленте изменений, как описано выше. Да, это звучит паршиво по сравнению с другими ответами, но это была моя первая идея до того, как эти ответы всплыли во время написания…

Текущие функции, связанные с этим вопросом, — это ограниченные коллекции (http://www.mongodb.org/display/DOCS/Capped+Collections) и, возможно, выполнение кода на стороне сервера (http://www.mongodb.org/display/DOCS/Server-side+Code+Execution).

С ограниченными коллекциями было бы проще записывать много данных, но меньше читать (например, файлы журналов) — этот тип коллекции создан для таких случаев. Скрипты на стороне сервера можно использовать для аутсорсинга большого объема обработки (меньше кода приложения), но вы можете пропустить этот пункт, если хотите полностью интегрировать логику в свое приложение.

Не знаю, есть ли NoSQL БД с "хуками". Я знаю, что это возможно в postgres (SQL).

В настоящее время логика потоковой передачи должна быть реализована в коде приложения AFAIK.

В CouchDB это возможно с «представлениями», которые не реализованы в MongoDB (если это не так, дайте ссылку, это тоже интересная тема!).

Не знаю, полезно ли это. Это моя первая попытка ответить здесь, на SO.

person asaaki    schedule 10.03.2011
comment
Кстати: хуки/фильтры в вашем приложении — это ключи. Вы должны подключиться к записи БД о желаемых моделях. - person asaaki; 10.03.2011

такие вещи нужно делать в приложении, а не в базе данных.

Это означает, что каждый раз, когда вы вносите изменение, оно должно быть записано как новая запись. Не модификация записи. Вы можете добавить гораздо больше интеллекта в свое приложение, если сделаете это таким образом.

person BenG    schedule 06.12.2011

Начиная с версии 3.6, MongoDB использует Change Streams, чтобы разрешить приложениям подписываться на список в реальном времени. изменений:

Потоки изменений позволяют приложениям получать доступ к изменениям данных в режиме реального времени без сложности и риска отслеживания оплога. Приложения могут использовать потоки изменений, чтобы подписываться на все изменения данных в коллекции и немедленно реагировать на них.

Потоки изменений могут принести пользу архитектурам с надежными бизнес-системами, информируя нижестоящие системы, как только изменения данных станут устойчивыми. Например, потоки изменений могут сэкономить время разработчиков при внедрении служб извлечения, преобразования и загрузки (ETL), межплатформенной синхронизации, функций совместной работы и служб уведомлений.

По умолчанию поток возвращает изменения для всех документов в коллекции, но вы можете добавить конвейер агрегации для фильтрации только тех документов, которые соответствуют вашему набору результатов запроса.

person Vince Bowdren    schedule 12.01.2018

Если получение всех изменений (а не только изменений в наборе результатов запроса) допустимо, вы можете создать ведомое устройство репликации mongodb и получать все изменения от мастера. Я видел подчиненное устройство репликации mongodb, написанное даже на php, поэтому реализовать это не должно быть слишком сложно.

person poiuyttr    schedule 10.03.2011

mongoDB реализует хвостовой курсор, но только для ограниченных коллекций. См. документацию. Это может быть полезно в зависимости от ваших конкретных требований.

person Rob Cowie    schedule 10.03.2011