Вопрос: postgreSQL против Кассандры против МонгоДБ против Волдеморта?


Какая база данных должна принять решение? Любые сравнения?

  • Существующие: postgresql
  • вопросы     
    • Не легко масштабируется по горизонтали. Требуется ошпаривание и т. Д.
    • Кластеризация не решает проблему роста данных
  • Поиск: Любая база данных, которая легко масштабируется по горизонтали     
    • Кассандра (Twitter использует это?)
    • MongoDB (быстро набирает популярность)
    • Волдеморт
    • Другие?
  • Зачем?     
    • Данные растут с эффектом снежного кома
    • существующая таблица блокировок postgresql и т. д. для периодических задач вакуумирования
    • Архивирование данных в настоящее время
    • Человеческое взаимодействие, связанное с существующим архивом, вакуумом, ... процессом периодически
    • Нужно «установить». забудь это. просто добавьте еще один сервер, когда данные растут больше ». тип решения

7
2018-05-03 15:43


Источник


Voldemart? Я искал ее, и мне хотелось, чтобы я посмотрел на Волдеморта. Злая магическая база данных? - Bart Silverstrim
Подожди, видимо, опечатка? Я думаю, что одна из ссылок не для Гарри Поттера, а для причудливого проекта с тем же именем. - Bart Silverstrim


Ответы:


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

Второй вопрос: какие данные вы храните? Вам кажется, что вам нужна база данных с хранилищем столбцов, и что это для какого-то проекта хранилища данных.

Третий вопрос: если вы застряли в PostgreSQL (который является прекрасной базой данных как есть), это текущая версия? Старые версии до 8.x, как известно, медленны, но много с тех пор работа улучшилась, и некоторые из проблем, которые вы упомянули, например, autovacuum, теперь легко решаются с настройками «установить и забыть».

*  Data growing with snowball effect

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

* existing postgresql locks table etc for vaccuum tasks periodically

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

* Archiving data is tideous currently

Трудно сделать какое-то суждение здесь, потому что с ним работать не так много. На каком носителе хранится архив? Сколько поддерживаемых операций ввода-вывода? С какими временными рамками вы работаете? Сколько данных? Нужно ли быть «горячим» дампом или может быть «холодным»?

* Human interaction involved in existing archive, vaccuum, ... process periodically

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

* Need a 'set it. forget it. just add another server when data grows more.' type of solution

Вы говорите об устройстве кластерного сервера.

Для меня это звучит так:

  1. Вы работаете на РСУБД, и транзакционный характер ее не подходит для вашего приложения.
  2. Ваше приложение, похоже, хочет получить стиль чтения в большинстве случаев. Также не похоже, что вам нужно иметь целостность транзакций.
  3. Объем данных, которые вы обрабатываете, скорее всего, не нормализуется, и не предпринималось никаких попыток его нормализовать.
  4. Вы делаете waaaaaay слишком много вручную и нуждаетесь в большей автоматизации.
  5. Вам нравится идея кластерного решения, возможно, «облачных» вычислений.

Кроме этого, здесь недостаточно информации, чтобы понять, какой будет хорошая подгонка.


9
2018-05-03 17:23





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

Некоторые вещи нужно иметь в виду:

Соединения выполняются вручную на платформах, отличных от SQL. Они не будут делать такие вещи, как внешние ключи, агрегаты и т. Д. Все это руководство.

Существующие приложения не всегда легко переносить. В зависимости от того, что будет стоить вам на порт, для вас может быть более рентабельным масштабировать сервер PostgreSQL по вертикали (а не по горизонтали).

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


3
2018-05-03 18:44





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

Я бы рекомендовал некоторые из статей примеров из http://wiki.apache.org/cassandra/ArticlesAndPresentations


0
2018-05-05 00:22



lol, «XXX - лучший вариант!» почему ради Пит? - Özgür
OP: «Поиск: любая база данных, которая легко масштабируется по горизонтали», среди всех баз данных, которые он перечисляет, только Cassandra отвечает этому требованию - Piotr Kolaczkowski


Что вы можете сделать, чтобы решить некоторые из ваших проблем:

  • Существующие таблицы блокировок postgresql и т. Д. Для периодических задач вакуумирования

Таблица не заблокирована, она работает медленно. Это делается с помощью postgresql, чтобы предотвратить обход идентификатора транзакции. Вы можете уменьшить частоту, записав несколько строк партиями, а затем зафиксировать. Вы можете использовать очередь (например, rabbitmq) для промежуточной записи: application-> queue-> db. Это также значительно увеличит вашу производительность записи.

  • Архивирование данных в настоящее время

Если ваши данные слишком велики в заказах нескольких TB, я бы предложил вам перейти в облако, потому что сброс не является вариантом. Используйте AWS или Google Cloud и используйте моментальные снимки. Например. Снимки EBS, которые очень быстры, реплицируются на континентах и ​​решают необходимость резервного копирования.

Если путем архивирования вы имеете в виду удаление данных и переходите к «архиву», используйте табличные пространства, которые вращаются по дате. Для этого есть несколько реализаций.


0
2017-08-25 12:23