|
Задавайте вопросы, мы ответим
Вы не зашли.
Доброго времени суток. Есть база (maria), состоящая из двух функциональных составляющих: юзеров и кое-каких юзерских логов (назовем их N). Сами юзеры проблем не вызывают: их и их данных хранится не много, бог с ними. Проблема в следующем. В базе, - по каждому юзеру, - содержатся логи действий N, которые пишутся/читаются со скоростью примерно 400-500 (пока) запросов в минуту. Всего записей планируется 30-40 млн, что примерно 60-80 гигов. Сравнительно не много, можно было бы воткнуть индексы и успокоиться, но с другой стороны, этого достаточно, чтобы начать доставлять неприятности при активной работе. Плюс не известно, какие входные данные будут, к примеру, через месяц, и будет паршиво, если придется перекраивать архитектуру. Идея в том, чтобы логи под каждого юзера хранить в отдельной таблице. Юзеров планируется не более 10к. Партицирование не сильно впечатлило по ряду причин. Стоит отметить, что никаких сложных выборок из более чем одной таблицы не планируется: тупо запрос данных по такому то юзеру и его логам, все. На сколько предложенный мною вариант адекватен моей ситуации и какие сильные/слабые стороны он имеет? С радостью бы выслушал любые комментарии по части такого способа разделения нагрузки (как минимум на будущее) и в целом архитектуре. Спасибо 
Отредактированно wenny (04.09.2012 06:57:09)
Неактивен
Ничего плохого в отдельных таблицах на пользователя, разумеется, нет
(ну, кроме небольшого усложнения заведения пользователя). Задумайтесь
над тем, какая нагрузка будет, какого вида будут запросы, сколько будет
чтений и сколько будет вставок. Без ответов на эти вопросы — не понятно,
что делать. Например, просто текстовые файлики с обычными журналами
Вам тоже подойдут
Неактивен
Добрый день.
Нет, я уже задумывался, просчитывал, данные примерно такие, какие привел.
Более подробно о запросах.
Таблица:
Отредактированно wenny (04.09.2012 16:06:16)
Неактивен
Ну то есть Вам нужен key-value storage, а не база данных, я Вас правильно
понимаю? Может, смотреть в этом направлении?
Сразу подумайте над тем, насколько удобно будет пользоваться такой системой.
Если единственный способ доступа к данным — это или листать 30кк записей
по 30 штук (сделать миллион листаний?), или знать заранее scanid, то это
не очень удобно, как мне кажется.
И Вы абсолютно ничего не сказали про нагрузку. Объем — понятно. Но он ничего
не говорит о нагрузке вообще.
Неактивен
Ну то есть Вам нужен key-value storage, а не база данных, я Вас правильно
понимаю? Может, смотреть в этом направлении?
Долго рассматривал nosql варианты, но в итоге так и не сумел определиться. Кассандра не проперла, остальное на винду не шло, а качать виртуалку было лень.. Решил в итоге задвинуть этот вариант, в конце-концов не те нагрузки/
P.S. Если поможете с выбором - буду очень благодарен, к сожалению, в сети не так много внятной инфы по этому поводу, не решился делать акцент на чем-либо.
Если единственный способ доступа к данным — это или листать 30кк записей
по 30 штук (сделать миллион листаний?)
Да зачем стока листать? Limit 30 и норм, с индексами вполне шустро даже в одной табле с 3 млн записей.
или знать заранее scanid, то это
не очень удобно, как мне кажется
Да это ваще труба :\
И Вы абсолютно ничего не сказали про нагрузку
Да как же не сказал-то?
Цитата:
которые пишутся/читаются со скоростью примерно 400-500 (пока) запросов в минуту
Отредактированно wenny (04.09.2012 17:47:00)
Неактивен
Как правило, если человеку нужны данные не из верхних 30, то он открывает
другие страницы, я только это имел в виду, когда говорил про листания
500 rpm — это 10 запросов в секунду, да? А соотношение запись-чтение какое?
А сколько данных в блобе в среднем?
На маленьких данных, например, обычная база MySQL держит ~3k rps на чтение.
Если совсем маленькие и хорошо тюненная, то ~15k. Но записей при этом будет
в разы меньше. Ну и понятно, что 10rps никого не испугают, какая бы архитек-
тура ни была Кроме случая больших блобов, когда база будет внезапно ездить
по диску для добывания этого содержимого (плюс время на отдачу).
Неактивен
Как правило, если человеку нужны данные не из верхних 30, то он открывает
другие страницы, я только это имел в виду, когда говорил про листания
Да меня сильно напрягало то, что при выборке тех же 30 строчек мускуль так хорошо призадумывался на 0.1 сек, хотя строк всего 3млн, что примерно 6 гектаров. А что будет с 20 млн? 1-1.5 сек? Не сурьезно нифига :\ Плюс ещё нагрузки сколько мускуль добавляет, шерстя бд..
В общем, решил действовать следующим образом. Попутно запускается MongoDB, в ней поселяется инфа со всеми идентификаторами (scanId), сгруппированная по юзерам. Итого имеем кол-во строк, равное кол-ву юзеров, двиг системы которых напрямую работает с рамом, что (судя по моим тестам) позволяет вытаскивать необходимую инфу с просто феноменальной скоростью. По памяти там не много выходит.
P.S. На сколько мне известно, нечто подобное фэйсбук реализовывал в движке поиска по своим мессагам. Там он какие-то хеши свои хранил (и по-моему хранит) в отдельном сторадже.
Отредактированно wenny (05.09.2012 06:33:20)
Неактивен
