Механизм хранения для конкретного случая

Какую базу данных вы можете порекомендовать для такого случая:

  1. Очень много вставок и обновлений
  2. Сложные запросы (SQL или что-то подобное)
  3. Много данных, но мало часто используемых (может быть в памяти)
  4. Можно потерять часть данных (например, последний час) в случае сбоя (но не все)

Возможные решения и проблемы с ним:

  • Redis — выглядит хорошо, но не поддерживает сложные запросы.
  • RDBMS (текущее решение) - гарантирует ACID и много использует жесткий диск, поэтому обновления выполняются слишком медленно.
  • РСУБД + RAM-диск - будет использовать подкачку ОС, проблемы с восстановлением и в целом выглядеть не очень надежно
  • MongoDB — имеет блокировку на уровне сервера при записи, действительно ли это быстро?

database mongodb redis memory rdms
person valodzka    schedule 16.02.2011    source источник

Ответы (3)


arrow_upward
0
arrow_downward

1.Очень много вставок и обновлений(Mobgodb).

4. Можно потерять часть данных (например, последний час) в случае сбоя (но не все)

Необязательные асинхронные записи в монго помогут здесь со скоростью. Скорость вставки/записи в mongodb будет выше, чем в sql, потому что mongo сначала записывает все данные в память, а mongodb не использует транзакции.

2. Сложные запросы (SQL или что-то в этом роде)

Если у вас много сложных отчетов, требующих объединения почти всех данных, лучше используйте sql здесь. Но если вам нужны жесткие запросы внутри документа, используйте mongodb (зависит от схемы sql/nosql db)

3. Много данных, но мало часто используемых (может быть в памяти)

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

Из-за того, что я фанатик mongodb, я выберу MongoDb, но без конкретной задачи не могу быть уверен, что выбор будет правильным. Также я сравнивал только sql и mongodb, потому что вообще не использую Redis.

person Andrew Orsich    schedule 16.02.2011
comment
Что такое запросы внутри документа? - person valodzka; 16.02.2011
comment
Я имею в виду запросы, для которых требуется только один документ (без соединений). - person Andrew Orsich; 16.02.2011

arrow_upward
1
arrow_downward

Реляционные Mysql/Postgresql + Partitions должны быть в состоянии решить варианты использования. MongoDb мог бы быть идеальным решением, за исключением двух причин.

  • Требуется достаточный объем оперативной памяти, чтобы гарантировать, что приличная часть базы данных находится в памяти.

  • Поддержка сложных запросов. Поскольку СОЕДИНЕНИЯ не поддерживаются, необходимо дублировать данные в нескольких местах ИЛИ СОЕДИНЕНИЯ должны выполняться в коде приложения.

  • Выполнение сложных аналитических запросов. Агрегация данных mongodb и mysql

Имел аналогичную ситуацию и оценивал postgresql против mongodb. Выбраны разделы postgresql + (разделение было выполнено по отметке времени) по вышеуказанным причинам.

Если набор данных упорядочен по времени или если каким-либо образом возможно разделение, обновления и запросы будут выполняться быстро.

Для mysql, если используется механизм хранения MYISAM (нетранзакционный), производительность улучшится еще больше за счет долговечности. Для СУБД, которая не позволяет отключать транзакции, производительность все же можно повысить, настроив интервал контрольных точек и несколько других параметров, которые гарантируют, что транзакции будут зафиксированы в непринужденной манере. Но если схема может часто меняться, решения РСУБД могут быть сложными.

person Anoop    schedule 19.02.2011

arrow_upward
0
arrow_downward

Сложные запросы и скорость вставки сейчас несовместимы. Если, конечно, эти запросы не известны заранее. Они?

person chx    schedule 16.02.2011