У нас в одном проекте товарищ написал на С++ свой data storage. Работает быстро, но глючно. Решил я тут попробовать на MySQL базу заюзать, честно говоря не ожидал, совсем не в восторге.
В базе одна таблица, примерно такая:
id int primary key,
msisdn varchar (11),
starttime datetime,
xdr blob(1024);
id, msisdn, starttime имеют индексы, именно по ним будет осуществляться поиск.
Предполагается хранить примерно около ~200 000 000 записей. Частая операция INSERT, UPDATE вообще не будет, DELETE не часто.
Сделал тестовое приложение, на С++. Вставка в чистую БД 200 000 000 записей заняла 10 часов примерно.
Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151';
Размер файла на диске занял 212Gb данные, 6Gb файл индексов.
Характеристики компа: IBM Blade HS20, два проца Intel Xeon, 4Gb памяти.
Что не так? В чём проблема? С удовольствием принимаю все советы и рекомендации.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Smooky, Вы писали:
S> Сделал тестовое приложение, на С++. Вставка в чистую БД 200 000 000 записей заняла 10 часов примерно. S> Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151';
Тип таблицы? msisdn — это текст или все же число и какой результат дал запрос выше (сколько там реально count)?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Smooky, Вы писали:
S>> Сделал тестовое приложение, на С++. Вставка в чистую БД 200 000 000 записей заняла 10 часов примерно. S>> Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151';
AB>Тип таблицы? msisdn — это текст или все же число и какой результат дал запрос выше (сколько там реально count)?
Тип MyISAM. msisdn — это текст, но поскольку в INT он может не влазить, то тип varchar(11). Результат 600 записей.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Smooky, Вы писали:
S>Здравствуйте, Anton Batenev, Вы писали:
AB>>Здравствуйте, Smooky, Вы писали:
S>>> Сделал тестовое приложение, на С++. Вставка в чистую БД 200 000 000 записей заняла 10 часов примерно. S>>> Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151';
AB>>Тип таблицы? msisdn — это текст или все же число и какой результат дал запрос выше (сколько там реально count)?
S>Тип MyISAM. msisdn — это текст, но поскольку в INT он может не влазить, то тип varchar(11). Результат 600 записей.
насколько разные первые N символов в msisdn? Если нет такого, что 99% записей начинаются с трех одинаковых цифр, то можно попробовать сделать индекс по первым N символам (чем больше N, тем больше размер индекса и пересчет его при инсерте). После создания индекса, попробуйте заново загнать весь датасет и засечь, сколько это займет. Будет однозначно больше, вопрос насколько. Основная часть запросо будет только с where msisdn='XXX'? Что говорит show create table `table` ?
Здравствуйте, odesk_worker, Вы писали:
_>Здравствуйте, Smooky, Вы писали:
S>>Здравствуйте, Anton Batenev, Вы писали:
AB>>>Здравствуйте, Smooky, Вы писали:
S>>>> Сделал тестовое приложение, на С++. Вставка в чистую БД 200 000 000 записей заняла 10 часов примерно. S>>>> Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151';
AB>>>Тип таблицы? msisdn — это текст или все же число и какой результат дал запрос выше (сколько там реально count)?
S>>Тип MyISAM. msisdn — это текст, но поскольку в INT он может не влазить, то тип varchar(11). Результат 600 записей.
_>насколько разные первые N символов в msisdn? Если нет такого, что 99% записей начинаются с трех одинаковых цифр, то можно попробовать сделать индекс по первым N символам (чем больше N, тем больше размер индекса и пересчет его при инсерте). После создания индекса, попробуйте заново загнать весь датасет и засечь, сколько это займет. Будет однозначно больше, вопрос насколько. Основная часть запросо будет только с where msisdn='XXX'? Что говорит show create table `table` ?
Можно попробовать сделать char(11) вместо варчара, но размер на диске тогда еще увеличится по идее.
Здравствуйте, Smooky, Вы писали:
S> S>> Сделал тестовое приложение, на С++. Вставка в чистую БД 200 000 000 записей заняла 10 часов примерно. S> S>> Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151'; S> AB>Тип таблицы? msisdn — это текст или все же число и какой результат дал запрос выше (сколько там реально count)? S> Тип MyISAM. msisdn — это текст, но поскольку в INT он может не влазить, то тип varchar(11). Результат 600 записей.
msisdn можно сделать типом BIGINT — в этом случае войдет число достаточного размера. К слову, на поле установлен NOT NULL?
Теперь что касается запроса — 6GB индекс, по хорошему, будет требовать ~6GB key_buffer_size (подробнее см. The MyISAM Key Cache) для более-менее быстрой работы.
Здравствуйте, odesk_worker, Вы писали:
_>насколько разные первые N символов в msisdn? Если нет такого, что 99% записей начинаются с трех одинаковых цифр, то можно попробовать сделать индекс по первым N символам (чем больше N, тем больше размер индекса и пересчет его при инсерте). После создания индекса, попробуйте заново загнать весь датасет и засечь, сколько это займет. Будет однозначно больше, вопрос насколько. Основная часть запросо будет только с where msisdn='XXX'? Что говорит show create table `table` ?
Да, возможно что первые 5 символов в msisdn будут во всех записях одинаковые.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
| test | CREATE TABLE `test` (
`id` int(11) NOT NULL auto_increment COMMENT 'Unique Identifier',
`msisdn` varchar(11) NOT NULL COMMENT 'Mobile Station Integrated Services Digital Number',
`starttime` datetime NOT NULL COMMENT 'Call Start Date Time',
`xdr` blob COMMENT 'XDR Record',
PRIMARY KEY (`id`),
KEY `idx_msisdn` (`msisdn`),
KEY `idx_time` (`starttime`)
) ENGINE=MyISAM AUTO_INCREMENT=223104342 DEFAULT CHARSET=latin1 |
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Smooky, Вы писали:
S>Здравствуйте, odesk_worker, Вы писали:
_>>насколько разные первые N символов в msisdn? Если нет такого, что 99% записей начинаются с трех одинаковых цифр, то можно попробовать сделать индекс по первым N символам (чем больше N, тем больше размер индекса и пересчет его при инсерте). После создания индекса, попробуйте заново загнать весь датасет и засечь, сколько это займет. Будет однозначно больше, вопрос насколько. Основная часть запросо будет только с where msisdn='XXX'? Что говорит show create table `table` ?
S>Да, возможно что первые 5 символов в msisdn будут во всех записях одинаковые.
Если такая ситуация вероятна, то, может, имеет смысл вынести этот префикс из 5 цифр первых в отдельную колонку? Зачем: для того, чтобы потом сделать индекс только по второй части , тогда теоретически where first_part = "XXX" and second_part = "YYY" будет его использовать, ну и как бонус, можно влезть в просто инт с каждой из частей? Но, конечно, такой подход заставляет менять код и разбирать в нем строку на две эти части.
S>id, msisdn, starttime имеют индексы, именно по ним будет осуществляться поиск.
судя по именам телефония?
S>Характеристики компа: IBM Blade HS20, два проца Intel Xeon, 4Gb памяти.
оперативки мало
S>Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151';
200GB / 30min =~ 100mb/sec, тупо полный скан — предсказуемый результат.
S>Что не так? В чём проблема?
в MySQL. <режим телепата включен> И будет в том что ты решил хранить сериализованные данные в блобе чтобы потом их массово читать и обрабатывать
S>С удовольствием принимаю все советы и рекомендации.
выкинуть MySQL и начать с описания бизнес-задач
Здравствуйте, Miroff, Вы писали:
Q>>Oracle. M>Вас не затруднит оценить производительность Oracle на той же задаче на данном железе?
У меня есть опыт сравнения Oracle и MySQL на одинаковых задачах на одинаковом железе. Не на таком, но в относительных тестах это не важно.
Здравствуйте, Miroff, Вы писали:
S>>Что не так? В чём проблема? С удовольствием принимаю все советы и рекомендации. M>Как минимум индекс должен целиком помещаться в память.
Ага, а лучше -- вся база. MySQL только в таких условиях работает нормально.
На Хабре кстате сведения не совсем точны... я где то читал блог одного из инженеров Фэйсбука, сцылку ща не найду, но там была примерно так: 1805 серверов — кластеры на MySQL, 807 servers memcached.
Это чтож получается, как только требуется решить задачу с более менее приличным кол-вом данных, то надо срочно бежать покупать Data Center где нить в Калифорнии?
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, quwy, Вы писали:
Q>У меня есть опыт сравнения Oracle и MySQL на одинаковых задачах на одинаковом железе. Не на таком, но в относительных тестах это не важно.
И? Результат-то огласите. Как себя поведет Oracle в случае одной большой таблицы у которой даже индексы не влезают в память. Мой опыт подсказывает, что чудес не бывает и цифры будут сопоставимы.
Здравствуйте, Smooky, Вы писали:
S>Всем привет!
S>У нас в одном проекте товарищ написал на С++ свой data storage. Работает быстро, но глючно. Решил я тут попробовать на MySQL базу заюзать, честно говоря не ожидал, совсем не в восторге.
S>В базе одна таблица, примерно такая: S>id int primary key, S>msisdn varchar (11), S>starttime datetime, S>xdr blob(1024);
S>id, msisdn, starttime имеют индексы, именно по ним будет осуществляться поиск. S>Предполагается хранить примерно около ~200 000 000 записей. Частая операция INSERT, UPDATE вообще не будет, DELETE не часто.
S>Сделал тестовое приложение, на С++. Вставка в чистую БД 200 000 000 записей заняла 10 часов примерно. S>Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151'; Именно такой запрос будет выполняться приметно одинаковое время для любой СУБД, так как сводится тупо к сканированию всей таблицы с поднятием её с диска.
В реальности же наверняка будут другие запросы, зачем оптимизировать структуру под этот искуственный?
Если же в приложении и вправду нужно знать количество записей, то можно его получать более быстрыми способами.
Здравствуйте, vmpire, Вы писали:
S>>id, msisdn, starttime имеют индексы, именно по ним будет осуществляться поиск. S>>Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151';
V>Именно такой запрос будет выполняться приметно одинаковое время для любой СУБД, так как сводится тупо к сканированию всей таблицы с поднятием её с диска.
Это почему вдруг? Если значения msisdn распределены достаточно равномерно нормальная СУБД не станет делать скан.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, vmpire, Вы писали:
S>>>id, msisdn, starttime имеют индексы, именно по ним будет осуществляться поиск. S>>>Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151';
V>>Именно такой запрос будет выполняться приметно одинаковое время для любой СУБД, так как сводится тупо к сканированию всей таблицы с поднятием её с диска. AJD>Это почему вдруг? Если значения msisdn распределены достаточно равномерно нормальная СУБД не станет делать скан.
Тьфу, простите, не заметил WHERE.
Ну вообще, да, именно этот приведенный мною запрос выдуманный, т.е. в реальной работе будут запросы на выборку msisdn в каком нибудь промежутке дат starttime, или на группировку с каким та msisdn'по дате. Но так или иначе, в требованиях, время выполнение запроса должно быть в пределах 1-5 сек, что вероятно не достижимо опираясь хотя бы на эти предварительные тесты.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Smooky, Вы писали:
S>Ну вообще, да, именно этот приведенный мною запрос выдуманный, т.е. в реальной работе будут запросы на выборку msisdn в каком нибудь промежутке дат starttime, или на группировку с каким та msisdn'по дате. Но так или иначе, в требованиях, время выполнение запроса должно быть в пределах 1-5 сек, что вероятно не достижимо опираясь хотя бы на эти предварительные тесты.
А сколько примерно записей на одну дату (всего и различный msisdn)?
За какой диапазон дат обычно делаются запросы?
А, спасибо огромное, интересная статья, надо провести тесты...
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, quwy, Вы писали:
Q>>У меня есть опыт сравнения Oracle и MySQL на одинаковых задачах на одинаковом железе. Не на таком, но в относительных тестах это не важно.
M>И? Результат-то огласите. Как себя поведет Oracle в случае одной большой таблицы у которой даже индексы не влезают в память. Мой опыт подсказывает, что чудес не бывает и цифры будут сопоставимы.
Да, сомневаюсь что для такой задачи вообще подойдёт решение в виде реляционной СУБД.
Но кстате, насколько я знаю, у заказчика будет дисковое поле, а не RAID SATA который у меня на тестовом серве. Говорят производительность резко увеличится, но к сожаоению пока нет возможности протестить.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, rm822, Вы писали:
S>>id, msisdn, starttime имеют индексы, именно по ним будет осуществляться поиск. R>судя по именам телефония?
да
S>>Характеристики компа: IBM Blade HS20, два проца Intel Xeon, 4Gb памяти. R>оперативки мало
возможно на таргет платформе будет 16Гб.
S>>Вот такой запрос выполняется 28 минут: select count(*) from test_table where msisdn='84537683151'; R>200GB / 30min =~ 100mb/sec, тупо полный скан — предсказуемый результат.
Именно.
S>>С удовольствием принимаю все советы и рекомендации. R>выкинуть MySQL и начать с описания бизнес-задач
Как сделано сейчас:
Mediation Device срёт на жёсткий диск примерно со скоростью 3000-5000 записей в секунду. Одна запись в данном случае, это бинарный файл 1024 байт. Как только файл появляется на диске, процесс который мониторит файлы импортит файлы-записи в raw data storage (как я уже упоминал, С++ приложение, которое использует boost::btree библиотеку из Boost'а для организации хранилища). Ну само собой, там не имеется никакого DB API, решение заточено именно конкретно под эту конкретную задачу, поэтому хранилище работает достаточно быстро. Далее из вне посредством своего протокола по сети поступает два запроса: 1) сначала на выборку по конкретному msisdn в каком та диапазоне дат, 2) далее уже из этого диапазона выборка конкретной записи.
Причём, как выяснилось уже потом, хранить требуется не 200 млн. записей, как я заюзал в тесте, а 60 млрд записей.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, quwy, Вы писали:
q> Ага, а лучше -- вся база. MySQL только в таких условиях работает нормально.
Не получится для MyISAM (как у ТС), т.к. этот тип таблиц в память не "всасывается" (самим сервером, кэш ФС в расчет не берем) и всегда берется с диска.
при таких объемах сразу понятно что
а) нужно сжатие данных
б) нужен партишнинг
в) кластерный индекс выбран неправильно, нужно делать date,msisdn
>>1) сначала на выборку по конкретному msisdn в каком та диапазоне дат
выборку каких именно полей? без блоба я так понял? >>2) далее уже из этого диапазона выборка конкретной записи.
какую часть от предыдущего запроса?
как часто они будут выполняться?
Здравствуйте, Smooky, Вы писали:
S>Ну вообще, да, именно этот приведенный мною запрос выдуманный, т.е. в реальной работе будут запросы на выборку msisdn в каком нибудь промежутке дат starttime, или на группировку с каким та msisdn'по дате. Но так или иначе, в требованиях, время выполнение запроса должно быть в пределах 1-5 сек, что вероятно не достижимо опираясь хотя бы на эти предварительные тесты.
Для любой СУБД из большой тройки это вполне выполнимые требования. Вопрос лишь в цене решения.
Здравствуйте, Smooky, Вы писали:
S>Всем привет!
S>У нас в одном проекте товарищ написал на С++ свой data storage. Работает быстро, но глючно. Решил я тут попробовать на MySQL базу заюзать, честно говоря не ожидал, совсем не в восторге.
Это ожидаемое поведение. Могу предолжить несколько вариантов:
Сделать таблицу:
id int,
msisdn varchar (11),
starttime datetime,
xdr blob(1024);
primary key (msisdn, id)
и тип InnoDB
Партиционировать ее по дате например, и уже в приложении делать разбиение
на даты (заодно даже параллелить и растащить по машинам можно).
Встроенное партиционирование не рекомендую.
S>Предполагается хранить примерно около ~200 000 000 записей. Частая операция INSERT, UPDATE вообще не будет, DELETE не часто. S>Что не так? В чём проблема? С удовольствием принимаю все советы и рекомендации.
Индекс не влез в память. Или запрос не правильный и full scan. Что explain говорит?
Теперь оффтоп: про Hbase. В моем тесте было
24Гб машинка
2 sata
210млн записей по 300 байт.
Данные: 300тыс случайных ключей из 210млн (считайте случайных msisdn)
Hbase (6Гб процесс бд занимал): 250rps/30-70ms (250 запросов в секунду с задержкой 30-70ms на выбрку, аналогичную
select * from some_tabkle where msisdn = <key> order by date desc limit 100 (тут не важно, т.к. в hbase данные всегда рядом лежат,
но пусть будет 100)
S>Что не так? В чём проблема? С удовольствием принимаю все советы и рекомендации.
Найди где MySQL flush-ит на диск данные (FlushFileBuffers). К примеру вот фикс для SQLite, кот. позволил добиться нам ускорения INSERT операции в 10 раз
/*
** Make sure all writes to a particular file are committed to disk.
*/static int winSync(sqlite3_file *id, int flags){
winFile *pFile = (winFile*)id;
OSTRACE3("SYNC %d lock=%d\n", pFile->h, pFile->locktype);
#ifdef SQLITE_TEST
if( flags & SQLITE_SYNC_FULL ){
sqlite3_fullsync_count++;
}
sqlite3_sync_count++;
#endif// if( FlushFileBuffers(pFile->h) ){return SQLITE_OK;
// }else{
// return SQLITE_IOERR;
// }
}
В случае если у вас комп с базой не будет постоянно самопроизвольно выключаться во время INSERT — абсолютно безопасный фикс. Если будет — добавьте бэкапов.
