СУБД для чрезвычайно больших наборов данных - что люди используют? - PullRequest
1 голос
/ 05 сентября 2011

Мне нужно провести серьезный анализ данных на очень больших наборах данных, хранящихся в базе данных MySQL. Однако запросы, требующие чуть больше базового SELECT * FROM X WHERE ..., имеют тенденцию становиться довольно неэффективными, поскольку они возвращают результаты порядка 10e6 или более, особенно когда вводится JOIN в одной или нескольких таблицах - подумайте о объединении 2 или более таблицы, содержащие несколько десятков миллионов строк (после фильтрации данных), что практически всегда происходит при каждом запросе. Чаще всего мы хотели бы запускать агрегатные функции на них (sum, avg, count и т. Д.), Но это невозможно, поскольку MySQL просто задыхается.

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

Это должно быть решаемой проблемой - многие крупные компании выполняют очень интенсивный анализ данных и вычислительных ресурсов и хорошо справляются (без написания собственных механизмов хранения, Google). Я готов принять штраф времени, чтобы сделать работу, но порядка часов, а не дней. Мой вопрос - что люди используют для борьбы с такими проблемами? Я слышал о механизмах хранения данных, предназначенных для решения этой проблемы (greenplum и т. Д.), Но я хотел услышать, как обычно решается эта проблема. Наше текущее хранилище данных явно реляционное и, вероятно, должно оставаться таковым, но любые мысли и предложения приветствуются. Благодаря.

Ответы [ 2 ]

2 голосов
/ 05 сентября 2011

Я предлагаю PostgreSQL, с которым я довольно успешно работал над таблицами со строками ~ 0.5B, которые требовали некоторых сложных операций соединения.Oracle тоже подойдет для этого, но у меня нет большого опыта в этом.

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

отредактировано исправлено несколько странных опечаток (бесполезное автокоррекция Android ...) и добавлено несколько ресурсов о материализованных представлениях

1 голос
/ 05 сентября 2011

Мы использовали MS SqlServer для запуска аналитики финансовых данных с десятками миллионов строк и более, используя сложное соединение и агрегирование. Несколько вещей, которые мы сделали, кроме того, что вы упомянули:

  • Мы разбиваем расчеты на множество временных таблиц вместо использования подзапроса. В этих таблицах мы применяем правильные ключи, индексацию и так далее через код. Запрос с подзапросом нам просто не удался
  • Во временных таблицах мы часто применяем кластерный индекс, который имеет для нас смысл. Обратите внимание, что эти временные таблицы являются фильтрованными результатами, поэтому применение индекса на лету не дорого по сравнению с использованием подзапроса вместо этих временных таблиц. Обратите внимание, что я говорю по нашему опыту и может не относиться ко всем случаям
  • Поскольку мы также выполнили много функций агрегирования, мы много проиндексировали столбцы группы
  • Мы много планируем выполнение запросов, используя SQL Query Analyzer , который показывает нам план выполнения. На основании плана мы пересмотрели запрос, изменили индекс
  • Мы предоставляем подсказки для SQL Server, которые, по нашему мнению, могут помочь при выполнении, такие как выбор алгоритма JOIN для принятия (хэш, объединенный или вложенный)
...