Что выбирать: SQL vs NoSQL?

Question

[Виталий Жук]

Привет всему хабрасообществу.

Решил все же дать жизнь своей мечте в создании одного не маленького проекта. И возникает вопрос, что же лучше использовать для Primary Storage?

На данный момент, думаю над PostgreSQL (MySql) или же каким-то NoSql решением (на примете Redis).

Задача проекта, это сбор информации с разных источников с большой скоростью.

Но вот, появляется куча ньюансов в из-за которых не могу определиться:

1. Редис все же быстрый (я бы сказал очень быстрый), но имеет больше процент потери данных при падании сервера чем реляционная БД
2. Редис не дает возможности явно указывать связи между сущностями.
3. БД (MySQL) при огромном количестве записей (ожидается более 20 млн записей) очень сильно начинает «тупить».

Поставленные требования:
1. Быстрая скорость записи/чтения
2. Возможность репликации на другие сервера
3. Фильтров почти нету, по сути, только списки.
4. Допустима потеря данных до 2%

Может кто-то сталкивался с такой задачей, и имеет опыт. Буду очень благодарен за ответы/советы. Спасибо!

Comments

[Виталий Жук]

UPD
Примерные характеристики сервера для первого старта:
Intel Core Duo i7, 32 Gb, ~ 1 Tb (берем на хетцнере).

Нагрузки на чтения/запись:
Запись: > 2000 — 3000 в секунду
Чтение: ~ 500 — 1500 в секунду (Тяжело сказать, так как будет зависеть от количества пользователей)

Answer 1

[WEBIVAN]

1) сильно сомневаюсь, что 32gb ram вам хватит на 20+млн записей, для редис
2)У редиса есть AOF при котором потери данных крайне маловероятны
3) Редис быстрый не потому что nosql, а потому что бд в ram
4) при корректно построенных индексах и структуре бд на 20 млн мускул не тупит, у нас на одном продакшн проекте в таблице сейчас 100 млн и все отлично шустро работает. кстати таблица переехала из редиса, когда тому перестало хватать РАМа, после тюнинга мускула быстродействие не пострадало.
5) Как выше написали, если делать инсерты пачками, а не по одному, это значительно ускорит работу бд
6)у хетцнера диски очень любят сыпаться, крайне не рекомендую их сервера. Сопоставимые цены у OVH, при явно лучшем качестве
7) Как показывает мой опыт, корректно настроенный SQL достаточен в 99% случаев

Comments

[Виталий Жук]

Большое спасибо!

Answer 2

[Пума Тайланд]

20 миллионов для mysql это ничто.

Comments

[Виталий Жук]

Возможно дело в конфигах (я в этом не очень силен:( ), но когда у нас было 24 млн записей, и использовались фильтры (по индексам), БД очень долго обрабатывала этого запрос.

[Пума Тайланд]

Это всего лишь значит что ваши фильтры не использовали индексы, а это значит что вы получите такой же результат на nosql решении.

[Виталий Жук]

Ну наверное я же не слепой был, когда писал тот запрос и смотрел по explain…

а это значит что вы получите такой же результат на nosql решении.

Ну если честно, мне кажется, что Вы здесь конкретно палку перегнули, или Вы можете показать, что скорость чтения/записи Redis == MySQL? Или же даже MongoDB == MySQL?

[Пума Тайланд]

Задайте пул в память для иннодб и оно будет читать на скорости 100 мегабайт в секунду, только сегодня видел это на одной виртуалке с толстым клиентом.
Я бы сказал что монго оно не столько производительнее сколько лучше масштабируется и шардируется из коробки.

[Виталий Жук]

Я бы сказал что монго оно не столько производительнее сколько лучше масштабируется и шардируется из коробки.

Но это уже другая сторона вопроса: что лучше будет поддерживаться/масштабироваться :)

Answer 3

[Кайгородов Алексей]

Перечисленным вами требованиям вполне удовлетворяет простая запись в файлы. Но вы этот очевидный вариант не рассматриваете, значит, он вам не подходит. По каким причинам не подходит — вы умалчиваете, но хотите получить совет. Чтож, это открывает простор для фантазий. Я вам советую Java-Chronicle или MapDB — самые быстродействующие решения.

Answer 4

[Дмитрий Гукетлев]

Если вам надо только читать\писать используйте постгре. С этими задачами она справляется вполне неплохо.

Comments

[Виталий Жук]

Здесь вопрос стал в скорости. Скорость в редиса будет намного выше.

[Дмитрий Гукетлев]

Скорости чего? Вставки? Выборки? Какие предполагаются нагрузки?

Если вставка и допустима потеря данных при падении, пробовали отключать wal?

[Дмитрий Гукетлев]

У постгре какие настройки? Вы надеюсь не на дефолтных запускали? Какие характеристики у сервера?

[Дмитрий Гукетлев]

Какая была методика определения того, что «Скорость в редиса будет намного выше.»? Или вы по статьям в интернете судите?

[Виталий Жук]

Относительно настроек, я не знаю, так как не я сервака админю.
Скорость и чтения и записи.

[Виталий Жук]

Какая была методика определения того, что «Скорость в редиса будет намного выше.»? Или вы по статьям в интернете судите?

Мы один проект запустили сначала на PostgreSQL (Doctrine 2), после чего для эксперемента перенесли на Редис. Скорость была более чем в 10 раз выше.

[Дмитрий Гукетлев]

Ну так проконсультируйтесь с админом. Сейчас я вам ничем помочь не могу. «У меня есть какой-то сервере с постгре, который я не знаю как настроен, и он медленнее чем редис который непонятно устанавливал ли я вообще. Определил я это чтением интернета, а не тестами».

Установите, настройте, проведите тесты и все поймете. Определите где у вас узкие места I\O, CPU, память. Попробуйте оптимизировать индексы. Проведите тесты еще раз. А так можно только на кофейной гуще гадать.

А если просто хочется поиспользовать NoSQL, но страшно и нужно одобрение сообщества, то используйте, я одобряю. Учтите только что там вас тоже ждет очень много очень неприятных эффектов.

[Дмитрий Гукетлев]

Уже лучше. :-) Теперь давайте разбираться с остальными вопросами. Скорость чего была выше?

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

1) постоянно писать поток телеметрии и иногда делать по нему выборку по ключам
2) разово (раз в день\час\неделю) впитывать большой объем данных и потом по неизменным данным строить выборки по ключам
3) впитать большой объем данных на старте, обрабатывать время от времени изменений\добавления и строить выборки по ключам
4) все тоже самое но сложные выборки с большим количество джоинов
5) ???

Answer 5

[r1alex]

MongoDB начиная с версии 2.4 вполне пригоден для продакшн. И репликация есть и отличная скорость. Используем в боевом проекте. Объем базы 32 Гб. Три реплики в реальном времени. Пишет только мастер. Читают только слейвы(у нас операций чтений больше почти в 20 раз)
На первый взгляд может показаться, что отсутствие реплики мастер-мастер — не есть гут. Однако в БД реализованы механизмы переизбрания мастера в случае падения.

Answer 6

[Сергей]

Лучше подумайте над тем какие преимущества дадут вам SQL против NoSQL. Сейчас модно говорить об NoSQL, но это всего лишь слова. А что вы будете делать когда схема БД будет меняться? Когда возникнут потребности в выборках которые вы не предусмотрели изначально? NoSQL хорош там, где нужна помощь SQL-решениям. Как самостоятельное primary решение я думаю его даже не стоит рассматривать.

Answer 7

[niko83]

Допустима потеря данных до 2%

Один из 50 insert'ов падает, и это приемлемо, я верно понял?

БД (MySQL) при огромном количестве записей (ожидается более 20 млн записей) очень сильно начинает «тупить»

Если структура данных вполне определена и поддаётся секционированию, возможно можно разбивать инфу по таблицам по месецам/неделям/ и др. ( смотря какой поиск будет производится)

1. Хотите быть гибкими чтоб поменять редис-могно-sql, подумайте об абстракции, используйте шлюз между вызывающим кодом и хранилищем. ( в таком случае кеширующую прослойку можно легко внедрить при необходимости)
2. Напишите тест генерирущий кучу предположительных запросов на чтение и на запись (если проект будет развиваться — пригодится)

(оба пункта дадум вам ценный полезный практический опыт)

Большой поток инсертов можно решить буферизирование на клиенте, и вставлять кучу строк за одну зоманду — Хорошая оптимизация, подумайте, возможно в вашем случае это вполне приемлемо.

Мне больше нравится как первичное хранилище реляционка, редис/монго и прочее как промежуточно хранение агрегированной инфы или для кеширование.

Answer 8

[EugeneOZ]

В первом пункте Вы сильно ошибаетесь — при дефолтных настройках он надёжнее Postgre.

Второй пункт — да, отличие от реляционных БД радикальное.

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

Answer 9

[IDVsbruck]

Для динамических данных (структура, связи, частый апдейт) — RMDB, для статики (текст, коллекции и т.д.) — NoSQL. Вполне можно сдружить в одном проекте.

Answer 10

[KEKSOV]

Посмотрите в сторону Percona Server + Percona NoSQL Это всем давно и хорошо известный MySQL. Где нужны сложные запросы для анализа данных — используете обычные SQL запросы, где нужна скорость — обращаетесь к тем же самым данным через NoSQL интерфейс. Еще один бонус — мастер-мастер репликация из коробки.