[sql][kvs] Разделение данных.

что такое kvs&

key value store — мемкэшед, редиска, токио кабинет, берклидб и тд и тп

я думаю это имеет смысл только в том случае если к самим варданным обращаются не часто, а к параметрам варданных часто.

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

может вначале побить табличку на кусочки?)

Не обязательно. Можно и в mysql все держать, если только правильно данные хранить. А для FT-search можно взять sphinx.

>Есть ли смысл вынести из sql базы тела сообщений, и поместить их в kvs?

Когда-то так и делал. Со временем оказалось, что не выгодно. На джойнах и дополнительных запросах оверхед выше.

А вот временные поля, которые извлекаются из других (компилированное в html тело сообщения, geoip из ip, браузер и ОС ил user-agent и т.п.) - реально удобно хранить в отдельной кеш-таблице, которую не жалко и грохнуть при работах. И объём основной базы в моём случае сразу вдвое меньше.

>А для FT-search можно взять sphinx.

Рулит, да. Но с некоторых пор я снова возвращаюсь частично и к использованию собственных индексов :) Больно уж хитрые, порой, преобразования при нормализации/стемминге слов нужны.

> Еще часто читаю, к примеру взять абстрактный mysql с 10 миллионной таблицей. И берут выборку данных, например с 5_000_000 по 5_000_020 записи, и она занимает около пары минут. Как же тогда Full text search/etc делают по таким большим таблицам?

сфинкс, не?

Больно уж хитрые, порой, преобразования при нормализации/стемминге слов нужны.

Дык и сам сфинкс тоже непростой? Я им не пользовался ни разу, если честно, но слышал что это хитрая и хорошо кастомизируемая система :)

А откуда джоинам взяться? :)

Я пока просто теоретизирую, на тему, почему все работает, если там traversing пару минут занимает. Хэши, b-деревья?

>но слышал что это хитрая и хорошо кастомизируемая система :)

По сравнению с альтернативами - да. Я в ней полноценно индексирую все параметры индексируемых объектов + любые сочетания фильтров при выборе. Очень удобно. Но это касается уже вопроса самой индексации и выборки. А вот то, как Сфинкс стемминг проводит и всё такое - это уже ненастраиваемые внутренности. Скажем, мне нужно все слова с одними прописными буквами индексировать как есть (аббревиатуры), а если хоть одна строчная - уже можно делать стемминг. Вот он так не умеет. Плюс нельзя при выборке сделать сортировку по заданному тобой критерию.

>А откуда джоинам взяться? :)

Так как ты тела сообщений будешь вытаскивать из второй? Либо лишний запрос + циклы по его обработке, либо джойн. Вот на больших базах (ну, по крайней мере на моих 2+млн. постингов на форуме и 2Гб чистых текстов) и выходит, что при разделении происходит потеря производительности.

>Еще часто читаю, к примеру взять абстрактный mysql с 10 миллионной таблицей. И берут выборку данных, например с 5_000_000 по 5_000_020 записи, и она занимает около пары минут.

Кстати, больной вопрос для форумов в многосотстраничными топиками. Раньше приходилось принудительно длинные топики убивать. Пока не стал хранить номер страницы прямо в таблице постингов. И не придумал быструю переиндексацию топика: http://www.linux.org.ru/jump-message.jsp?msgid=3881616&cid=3882698

Теперь от размера темы скорость выборки последних страниц не зависит :)

Кстати про джоины, смысл таков, что KVS без проблем хранит всё в хэштаблице, где в идеале время чтения/записи/изменения составляет O(1). Ну и масштабируются они на раз-два.

>Кстати про джоины, смысл таков, что KVS без проблем хранит всё в хэштаблице, где в идеале время чтения/записи/изменения составляет O(1).

O(1)? Ты точно ничего не путаешь? :)

В любом случае, в идеале, при чтении из SQL-таблицы по индексу зависимость должна быть такого же уровня. То же самое чтение по ключу. И на практике так и есть. Из миллионных таблиц десяток-другой записей извлекаются за миллисекунды или десятки миллисекунд.

Ну и масштабируются они на раз-два.

Это - уже другой вопрос, да.

O(1), да.

b-деревья — O(log n).

Тут выигрыш по идее идет за счет traversing speed.