Выбор MongoDb/CouchDb/RavenDb - рекомендации по производительности и масштабируемости

Ответ 1

Если "20 000 одновременных записей" означает "вставки", я бы пошел на CouchDB и использовал "_changes" api для триггеров. Но с 20 тысячами записей вам также понадобится стабильный осколок. Тогда вам лучше взглянуть на bigcouch

И если "20.000" одновременных записей состоят из "в основном" обновлений, я бы наверняка пошел на MongoDB, так как его "обновление на месте" довольно удивительно. Но тогда вы должны обрабатывать триггеры вручную, но при использовании другой коллекции для обновления на месте общий документ может быть удобным решением. Снова будьте осторожны в отношении осколков.

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

Ответ 2

Я бы порекомендовал MongoDB. Мои требования были не так высоки, как у вас, но были достаточно близки. Предполагая, что вы будете использовать С#, я рекомендую официальный драйвер MongoDB С# и метод InsertBatch при включенном SafeMode. Он будет буквально записывать данные так же быстро, как ваша файловая система может обрабатывать. Несколько предостережений:

• MongoDB поддерживает не триггеры поддержки (по крайней мере, в последний раз, когда я проверял).
• MongoDB изначально кэширует данные в оперативную память перед синхронизацией с диском. Если вам нужны в реальном времени потребности с долговечностью, вы можете установить fsync ниже. Это будет иметь значительный успех.
• Драйвер С# немного неудобен. Я не знаю, если это только я, но я получаю странные ошибки всякий раз, когда я пытаюсь запустить с ним какие-либо длительные операции. Драйвер С++ намного лучше и быстрее, чем драйвер С# (или любой другой драйвер, если на то пошло).

Сказав это, я также порекомендую посмотреть в RavenDB. Он поддерживает все, что вы ищете, но для жизни меня, я не мог заставить его работать где-нибудь рядом с Монго.

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

Ответ 3

Membase (и скоро будущий Couchbase Server) легко справится с вашими потребностями и обеспечит динамическую масштабируемость ( "на лету" добавить или удалить узлы), репликацию с отказоустойчивостью. Кэш-память memcached сверху будет легко обрабатывать 200 тыс. Операционных систем/сек, и вы можете линейно масштабировать с помощью нескольких узлов, чтобы поддерживать получение данных, сохраняемых на диске.

У нас есть некоторые недавние тесты, демонстрирующие чрезвычайно низкую задержку (что примерно соответствует высокой пропускной способности): http://10gigabitethernet.typepad.com/network_stack/2011/09/couchbase-goes-faster-with-openonload.html

Не знаю, насколько важно для вас поддерживать поддерживаемый продукт корпоративного класса с инженерными ресурсами и ресурсами QA, но это тоже доступно.

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

Перри

Ответ 4

• Мы рассматриваем решение для хранения данных db с отказоустойчивостью кластеризации, для некоторых приложений с интенсивным чтением/записью

Riak с бэкэндом Google LevelDB [здесь замечательный бенчмарк от Google], учитывая, что достаточно кеша и сплошных дисков очень быстро. В зависимости от структуры документа и его размера (вы упомянули 2KB) вам, конечно же, нужно будет сравнить его. [Имейте в виду, что если вы можете очертить свои данные (бизнес-мудрый), вам не нужно поддерживать пропускную способность 40 Кбит/с на одном node]

Другим преимуществом LevelDB является сжатие данных = > хранилище. Если хранилище не является проблемой, вы можете отключить сжатие, и в этом случае LevelDB будет буквально летать.

Riak со вторичными показаниями позволяет вам создавать структуры данных, как указано в вашем формате = > вы индексируете только те поля, которые вам интересны при поиске.

Успешное и безболезненное Fail Over - второе имя Риак. Это действительно сияет здесь.

• Нам также нужен механизм для того, чтобы db сообщал о новых записанных записях (какой-то триггер на уровне db)

Вы можете положиться на pre-commit и post-commit hooks в Riak для достижения такого поведения, но опять же, как и любые триггеры, он имеет цену = > производительность/ремонтопригодность.

• Вставки должны быть доступны для чтения сразу - почти в режиме реального времени

Riak записывает на диск (без асинхронных сюрпризов MongoDB) = > reliably readable сразу. Если вам нужна более четкая согласованность, вы можете настроить кворум Riak для вставок: например. сколько узлов должно вернуться до того, как вставка будет считаться успешной

В общем, если fault tolerance/concurrency/Fail Over/scalability важны для вас, я бы пошел с хранилищами данных, которые написаны в Erlang, так как Erlang успешно решает эти проблемы уже много лет.