 |
|
Модераторы: LSD |
 
|
|
Помогите подобрать СУБД 
| BuShaRt |
|
|||
|
Эксперт  Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Есть bigdata, размером:
1. 60 000 000 объектов 2. Порядка 12 gb Data lenght в MySQL (размер индексов не указываю). Требования * У каждого объекта примерно 20 атрибутов типа integer, по которым может производиться выборка (как по одному атрибуту, так и любому количество атрибутов одновременно) т.е. по сути 20 атрибутов достойны стать индексами. * Добавлять/обновлять примерно по 50000 записей в сутки - не меньше (больше можно =) * Скорость любой выборки не более 500 мс * Поддержка группировки и агрегации в выборках MySQL быстро делать выборки отказалась почти сразу. В панике прикрутили Sphinx - он вроде как лучше работает, но все равно желаемых 500 мс добиться не вышло. Приглядываемся к ElasticSearche. Ребят, возможно мы ищем не в том направление? Возможно та же mongoDb, без индексов будет работать шустрее? Или может стоит делать виртуальную реплику этой таблицы? Расскажите, пожалуйста, что вы об этом все думаете? Это сообщение отредактировал(а) BuShaRt - 7.4.2014, 20:32 |
|||
|
||||
Загрузка ...
| Akina |
|
||||||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Только AND или и другие варианты?
Бред. Неудивительно, что
-------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
||||||
|
|||||||
| BuShaRt |
|
||||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Скорее всего только AND
Кто же спорит? Это был промежуточный вариант по большей части для некоторой иследовательской работы. Вопрос то не в этом =) |
||||
|
|||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
В этом. На описанной структуре и для описанной задачи разница между различными СУБД будет незначительной.
-------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| BuShaRt |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Так, что же делать? Неужели вычислительная мощность современных программно-аппаратных комплексов (массового производства) не способна справиться с поставленной задачей? Я же не ставлю условия, что данные должны храниться именно в СУБД или вообще использовать б-индексы и т.п. (Выбор на раздел СУБД выпал только по той причине, что это наиболее подходящий раздел в контексте других).
|
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Покажите лучше структуру, которая была создана под описанную задачу, и тот запрос, на котором MySQL "провалился", в форме explain.
-------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| BuShaRt |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Нет ни какой особенной структуры. Есть 1 таблица в которой 1 объект = 1 строка. Можно представить как id (int), param1(int) ... param20(int). Запросы не проваливаются, а выполняются слишком долго (от 5 секунд до бесконечности, а по условию мы хотим чтоб скорость выполнения запроса была менее секунды).
За сегодня мы протестировали ElasticSearche и он показал хорошие результаты, выполнив часть задач (за счет Facet Searche и агрегаций), но в нем нет группировки в том виде, в каком она есть в MySQL, поэтому есть еще черные пятна. Если говорить конкретно, то он не может выполнить запрос типа SELECT distinct param1 FROM table ORDER BY param2, где мы хотим получить список уникальных значений param1, отсортированные по param2. Это конечно расстраивает, но от поискового движка я большего и не ожидал. Как думаете, CouchDB сможет выполнить задачу описанную в сабже + этом сообщение? |
|||
|
||||
| Akina |
|
||||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
ТО есть совершенно очевидная бессмысленность такого запроса Вам даже не видна?
Покажите лучше структуру, которая была создана под описанную задачу, и тот запрос, на котором MySQL "провалился" который выполняется более полусекунды, в форме explain. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
||||
|
|||||
| BuShaRt |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Возможно я что-то не учел в запрос, поэтому приведу более точный пример SELECT country FROM cities ORDER BY max(population) GROUP BY country; В таблице храниться список городов и мы на основание этой таблицы хотим получить: "Список стран, отсортированный по количеству жителей в самом населенном городе каждой страны".
По поводу инфраструктуры, уточните пожалуйста, что еще я могу уточнить касательно ее? Если абстрактная table (id, param1 (int), ..., paramN (int)) не слишком понятна, я могу привести такой пример. cities (id(int), country(int), region(int), pipulation(int), crimeLevel(int), turistLevel(int), latitude(int), longitude(int), ну и еще дюжина цифровых параметров, которые могут характеризовать город). Все храниться в одной таблице и все поля - индексы. Все это в MySQL на сервере, без реплик, кластеров и т.п. К сожалению информации о реальной таблице я предоставить не могу т.к. NDA. |
|||
|
||||
| Akina |
|
||||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
При наличии индекса по (country, population) запрос должен лететь. И лимитирующим звеном будут либо пустой кэш, либо сетевой канал передачи данных от сервера. Ну и для соблюдения синтаксиса надо две последние секции местами поменять, есссно.
Вот-вот... достаточно редко индекс по одиночному полю эффективен - чаще получается так, что составные индексы эффективнее. Но поскольку на каждый чих не наздравствуешься - приходится искать компромисс между расходом дискового пространства на чёртову кучу индексов и быстродействием запросов. Естественно приоритет отдаётся тем наборам индексов, которые повышают эффективность выполнения более часто выполняющихся запросов. Плюс учёт кучи дополнительных факторов - ну там сколько памяти можно отдать на разные нужды, умеет ли СУБД мержить индексы, и т.д., и т.п... Впрочем, индексы вовсе не единственный способ повышения эффективности. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
||||
|
|||||
| BuShaRt |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Akina, Я правильно понял, что 60 000 000 записей должны летать в MySQL, если операции идут по правильно проиндексированным полям, а база данных, сервер и инфраструктура корректно настроены?
Это сообщение отредактировал(а) BuShaRt - 9.4.2014, 13:56 |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Да, скорость обработки должна быть высокой. Впрочем, конкретных цифирей в секундах не дам. Как я понимаю, у тебя есть реальная база. Ну так и попробуй прямо на ней скорость обработки своего запроса с указанным индексом и без него. Заодно просмотри скорость работы с пустым и набитым кэшем. Движок лучше MyISAM - судя по описанию таблицы, транзакционности на ней не требуется.
-------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| BuShaRt |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Провел эксперимент на свое личном компьютере (Fedora 20, 16gb, i5, количество процессов стремиться к нулю). Как видим из 47117231 миллионов записей, используя индекс, самый простой запрос выполнялся почти 7 секунд. Если добавить в запрос еще GROUP BY и WHERE то может на минуту "потеряться". Это сообщение отредактировал(а) BuShaRt - 10.4.2014, 19:24 |
|||
|
||||
| tzirechnoy |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1173 Регистрация: 30.1.2009 Репутация: 0 Всего: 16 |
Учитывая, что всегда можно придумать логичный запрос, который ответит полным набором данных, а полный набор данных у нас 12GB -- можно сделать вывод, что нужна производительность как минимум 24GB/s. Это скорость памяти на средненькой машыне. Из этого следует, в первую очередь, что все данные должны быть в RAM. Для ультра-параллельной обработки можно было бы ещё подумать о том, чтобы расшардить их на 500 компьютэров, и брать у каждого с диска но, думаю, у Вас такого параллелизма всё равно нет, чтобы это развлечение окупилось. Во вторую -- что лишних копирований мы можэм себе позволить на хорошэм сервере максимум пару. То есть все варианты вроде mysql/postgresql потребуют конкретного допиливания сервера. И, в общем, начать я бы посоветовал с допиливания postgresql, но прицэливаться на то, что придётся писать свой обработчик -- ужэ бы прицэливался. Ну, и в третью, что, похожэ, автор перемудрил с условиями и на самом деле ему это нафиг не нужно. |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
На предложенной в качестве образца структуре (страны, города, население) требование в полсекунды действительно выглядит вакханалией абсурда... -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0755 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |