Запоминающее устройство для конкретного случая - PullRequest
Новая
       20

Запоминающее устройство для конкретного случая

1 голос
/ 16 февраля 2011

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

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

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

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

Ответы [ 3 ]

1 голос
/ 19 февраля 2011

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

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

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

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

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

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

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

0 голосов
/ 16 февраля 2011

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

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

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

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

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

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

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

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

0 голосов
/ 16 февраля 2011

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

...