Лучшая база данных для этого варианта использования? MongoDB не в масштабе

Question

Работает над приложением типа «очень забыл и забыл», веб-приложение для сканирования, которое собирает тысячи и тысячи элементов (часто миллионы) из inte rnet и сохраняет их в коллекции не sql ( в настоящее время для этого используется MongoDB). Эти коллекции очень изменчивы, что означает, что они создаются и очень быстро отбрасываются. Доступ к данным также очень случайный, поэтому теоретически мое приложение может создавать коллекцию, когда система активна, и отбрасывать, когда система тоже работает, - а также, коллекция, созданная месяцами go, будет доступна случайным образом для обновлений. и читает. Я говорю о тысячах и тысячах коллекций с потенциально миллионами документов каждая.

Короче говоря, проблема с MongoDB заключается в том, что в этом контексте она работает плохо. Их кэш и механизм WiredTiger спроектированы таким образом, что не готовы обрабатывать произвольный доступ к коллекциям и динамически создавать и удалять коллекции. Репликация стала кошмаром, и часто записи останавливаются, и база данных по существу получает невероятное резервное копирование. Масштабирование моего приложения тысячами и тысячами пользователей, к сожалению, не является чем-то вроде go.

Итак, с учетом сказанного - кто-нибудь знает или может порекомендовать базу данных, которая подходит для этого типа рабочей нагрузки? Мы используем гео-индексы и полнотекстовые индексы, так что в основном это будет единственным требованием. Я открыт для изучения и экспериментирования с чем угодно, предпочтительно с графической базой данных, но производительность и готовность к работе имеют ключевое значение.

Answer 1

Настоятельно рекомендуется для сценария использования «забей и забудь» Apache Cassandra или даже лучше ScyllaDB (насколько я понимаю, Cassandra на стероидах переписана с нуля в C ++ для лучшей производительности). Вы можете сделать поиск в Google для сравнения производительности, оба превосходны в случае производительности записи (не так уж велика в производительности чтения, пожалуйста, обратите внимание, что я сказал «не так здорово», неплохо или плохо).

Apache Cassandra бесплатна для коммерческого использования, так что это еще один зеленый свет для go. Синтаксис очень похож на SQL (пожалуйста, не так много, как не SQL), поэтому его относительно легко выучить быстро. Кроме того, мы успешно запустили его на кластерах серверов GNU / Linux и Microsoft Windows.

Как и в случае с Cassandra, ScyllaDB почти схожим синтаксисом.

В моем случае мы Я управлял кластерами Cassandra уже почти 3 года и перенес все наши рабочие процессы и предыдущие проекты исключительно на Apache Cassandra. Я мог бы express получить только хорошие впечатления относительно производительности, хотя самое трудное вначале - понять базовые c концепции внутренней работы и образ мышления Кассандры "запрос в первую очередь перед моделью данных".

Я надеюсь, что это поможет вам в ваших исследовательских поисках.

Answer 2

Вы не говорите, что конкретно проблематично c в существующем развертывании MongoDB - «резервное копирование базы данных» не является отчетом о проблемах, требующих действий.

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

У меня сложилось впечатление, что у вас может быть один набор реплик, который огромен, когда вы выполняете интенсивное чтение и запись по всему набор данных И вы делаете DDL в то же время. Я не знаю, какие базы данных предназначены для такого типа рабочей нагрузки, но моя первая реакция - разделить набор данных на более мелкие части.

То, что MongoDB предлагает, в частности, является чрезвычайно богатым языком запросов для всего набора данных. и поддержка как транзакционных, так и аналитических вариантов использования. У меня сложилось впечатление, что многие из нереляционных хранилищ данных (включая мое впечатление о Cassandra, хотя оно восходит к 2010 году или около того и не является актуальным) не поддерживают такой спектр вариантов использования. Конечно, они могут предложить лучшую производительность, но с гораздо меньшим набором функций. Поэтому в качестве альтернативы я бы рассмотрел, например, шардинг, который переносит больше усилий на приложение из базы данных, но вы все равно можете, например, сохранять транзакции MQL и ACID, если вы хотите их.

Я не знаю какую настройку вы проделали - не предполагая, что вы сделали недостаточно, но вопрос, который вы здесь задаете, в основном «У меня есть набор данных объемом 10 ТБ, и мне нужна быстрая база данных для него». Учитывая этот уровень детализации, вы скорее всего получите список хранилищ данных.