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

Question

Какая база данных 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
...

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

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

Спасибо,

Крис.

Answer 1

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

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

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

Answer 2

Несмотря на то, что ответ был принят, есть другой ответ, который лежит в основе предположений под вашим вопросом.

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

).

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

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

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

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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