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

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

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

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

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

3 ответа

Решение

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

Источник

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

Источник
Другие вопросы по тегам