2013-11-01 3 views
-1

есть набор данных с около 6 миллионами записей. Каждая запись имеет одинаковое количество полей. Есть 8 полей итого:Лучшее решение SQL NoSQL для определенных требований?

ID Title Color Date1 Date2 Date3 Date4... 

Там должен быть способ, чтобы отфильтровать эти записи по названию и всех полей даты (или, «колонн» в терминах реляционных СУБД).

Размер данных не такой огромный, около нескольких гигабайт. У нас нет длинных текстовых полей и т. Д. (Мы избавились от них во время создания архитектуры, поэтому теперь у нас есть только действительно важные поля в наборе данных).

Бэкэнд читает &, пишет данные довольно интенсивно. Нам бы очень хотелось ускорить как чтение, так и запись (и фильтрацию по полям) как можно больше. В настоящее время мы используем Postgres, и нам нравится его надежность, но, похоже, это не очень быстро. Да, мы сделали некоторую настройку и оптимизацию, добавили индексы, установили ее на 32 ГБ оперативной памяти и установили все необходимые настройки. Другими словами, он работает, но я по-прежнему считаю, что это может быть лучше. Нам нужна скорость: фильтрация записей по датам и названиям должна быть быстрой, очень быстрой. Вставка данных может быть медленнее. Бэкэнд фильтрует все записи, которые не обрабатывались, обрабатывали его и устанавливали флаг даты (времени datetime, когда он был обработан). Каждые 5-10 секунд выполняются около 50 бэкэнд-рабочих, поэтому БД должна быть в состоянии выполнять очень быстро. Кроме того, мы выполняем некоторые итерации DB (вид карты \ сокращение заданий), поэтому решение БД должно быть в состоянии выполнить такие задачи (СУБД здесь не очень хорошо).

У нас нет объединений, данные уже оптимизированы для решения больших объемов данных. Только один «большой стол».

И мы хотели бы запустить его на одном узле или во многих небольших экземплярах. Данные не очень важны. Но мы хотели бы избежать дорогостоящих решений, поэтому мы ищем решение SQL или NoSQL, которое будет работать быстрее, чем Postgres на том же дешевом оборудовании.

Помню, я пробовал MongoDB около года или два назад. Из того, что я помню, фильтрация была не такой быстрой. Кассандра была лучше, но я помню, что она могла выполнять только малые подмножества фильтрующих запросов. Riak хорош, но только для большого кластера с множеством машин. Это мой самый базовый опыт, если вы, ребята, знаете, что одно из этих решений отлично работает, напишите об этом. Или предложите другое решение.

Спасибо!

+3

«Размер данных не такой огромный, около нескольких гигабайт». - Это крошечный для Postgres. Он может (и делает) обрабатывать базы данных в тысячу раз больше без каких-либо проблем с производительностью. Придерживайтесь того, что вы в настоящее время используете; просто научитесь использовать его лучше. –

ответ

1

Я согласен с Денисом, что вы должны придерживаться Postgres. По моему опыту, реляционные базы данных при правильной настройке имеют невероятно быстрые результаты. Или по-другому ... Мне было гораздо сложнее настроить Mongo, чтобы получить сложные запросы, возвращающиеся в 10 мс или меньше, чем я настраиваю SQL Server и MySQL.

Прочтите этот сайт http://use-the-index-luke.com/ за идеи относительно дальнейшей настройки. Парень также написал книгу, которая, вероятно, будет полезна для вас.

Как и Денис, размер данных не такой большой, что стоило бы начать с нуля с помощью решения NoSQL.

+0

В качестве примечания, vanilla PostgreSQL обрабатывает базы данных в десятках TB по размеру, и с такими вещами, как Postgres-XC или подходы, такие как федеративное хранилище, вы потенциально можете получить много раз этот размер. Кроме того, я ожидаю, что в конечном итоге основные узкие места в больших наборах данных будут рассмотрены, поэтому я бы не стал рассматривать размер вообще. –

2

Я согласен с Райаном выше. Придерживайтесь PostgreSQL.

Вы не описали, как на самом деле нравится ваша нагрузка на запись (вы обновляете несколько записей здесь и там, но с множеством параллельных запросов? Обновление с меньшим количеством параллельных запросов, но много строк, обновленных на один раз и т. д.). Поэтому я не могу сказать вам, что вам нужно сделать, чтобы получить больше скорости.

Однако, исходя из вашего вопроса и того, что вы говорите, вы пробовали до сих пор, я бы посоветовал вам рассмотреть возможность найма консультанта, чтобы посмотреть на ваш дБ, посмотреть на свою среду и т. Д. Свежими глазами и предложить улучшения. Я предполагаю, что у вас много вещей, которые можно было бы оптимизировать довольно много, и вы потратите гораздо меньше на такие оптимизации, чем на переход к новой среде.

Смежные вопросы