Ну вообще, да, именно этот приведенный мною запрос выдуманный, т.е. в реальной работе будут запросы на выборку msisdn в каком нибудь промежутке дат starttime, или на группировку с каким та msisdn'по дате. Но так или иначе, в требованиях, время выполнение запроса должно быть в пределах 1-5 сек, что вероятно не достижимо опираясь хотя бы на эти предварительные тесты.

Здравствуйте, Smooky, Вы писали:

S>Ну вообще, да, именно этот приведенный мною запрос выдуманный, т.е. в реальной работе будут запросы на выборку msisdn в каком нибудь промежутке дат starttime, или на группировку с каким та msisdn'по дате. Но так или иначе, в требованиях, время выполнение запроса должно быть в пределах 1-5 сек, что вероятно не достижимо опираясь хотя бы на эти предварительные тесты.
А сколько примерно записей на одну дату (всего и различный msisdn)?
За какой диапазон дат обычно делаются запросы?

Здравствуйте, Smooky, Вы писали:


S>Что не так? В чём проблема? С удовольствием принимаю все советы и рекомендации.

Посмотри вот сюда

http://l-o-n-g.livejournal.com/153756.html

Сам, правда, не пробовал.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Smooky, Вы писали:


S>>Что не так? В чём проблема? С удовольствием принимаю все советы и рекомендации.

PD>Посмотри вот сюда

PD>http://l-o-n-g.livejournal.com/153756.html

А, спасибо огромное, интересная статья, надо провести тесты...

Здравствуйте, 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 — абсолютно безопасный фикс. Если будет — добавьте бэкапов.

Здравствуйте, quwy, Вы писали:

S>>С удовольствием принимаю все советы и рекомендации.
Q>Oracle.

А лампочку как поменять, не подскажешь? ;)