С одной стороны пост в Базы Данных, а с другой — все же про мнезию.
Так вот, возникла такая проблема — есть некоторое количество условных пользователей — допустим, 10K. Каждый генерирует поток событий, в пределе где-то 2 события в минуту, ну реально какие-то работают, какие-то могут не работать, все как обычно. Каждая запись — ну, допустим, 500 байт, учитывая 4-гигабайтное ограничение — можно легко посчитать, когда оно все умрет.
Есть индекс — ну грубо говоря, по дате и id пользователя. Надо что бы это все хотя бы вообще жило. Т.е. вариант, когда все хранится в одной таблице выглядит не очень хорошо, помимо быстрого роста таблицы еще и растет время вставки данных постоянно; вероятно — за счет перестройки индексов.
Есть мнение, что надо таблицу кластеризовать по пользователям, при этом дойти до предела — т.е. одна таблица на одного пользователя. Плюсов тут видится достаточно много — возможность плавной кластеризации, миграции таблиц по нодам, легкость архивации и вообще майнтейнанса.
Какие минусы — ну кроме того, что это дурной тон и никто так не делает (в реляционных базах за такое убивают) ?
Здравствуйте, dmz, Вы писали:
dmz>Есть мнение, что надо таблицу кластеризовать по пользователям, при этом дойти до предела — т.е. одна таблица на одного пользователя. Плюсов тут видится достаточно много — возможность плавной кластеризации, миграции таблиц по нодам, легкость архивации и вообще майнтейнанса.
dmz>Какие минусы — ну кроме того, что это дурной тон и никто так не делает (в реляционных базах за такое убивают) ?
Мнезия не совсем реляционная БД, для мнезии обычно фрагментацию делают люди вроде как (сам не ковырялся), правда вменяемой доки по использованию фрагментации я чтот не припомню.
Здравствуйте, Курилка, Вы писали:
К>Мнезия не совсем реляционная БД, для мнезии обычно фрагментацию делают люди вроде как (сам не ковырялся), правда вменяемой доки по использованию фрагментации я чтот не припомню.
Блин, и чего я думал, что в офдоках ничего нет? Всё есть.
dmz>>Какие минусы — ну кроме того, что это дурной тон и никто так не делает (в реляционных базах за такое убивают) ?
К>Мнезия не совсем реляционная БД, для мнезии обычно фрагментацию делают люди вроде как (сам не ковырялся), правда вменяемой доки по использованию фрагментации я чтот не припомню.
Фрагментация только отсрочит смерть, на самом деле. Сделать по таблице на источник — это просто предельный случай фрагментации.
К>>Мнезия не совсем реляционная БД, для мнезии обычно фрагментацию делают люди вроде как (сам не ковырялся), правда вменяемой доки по использованию фрагментации я чтот не припомню.
dmz>Фрагментация только отсрочит смерть, на самом деле. Сделать по таблице на источник — это просто предельный случай фрагментации.
dmz>>>Какие минусы — ну кроме того, что это дурной тон и никто так не делает (в реляционных базах за такое убивают) ?
К>>Мнезия не совсем реляционная БД, для мнезии обычно фрагментацию делают люди вроде как (сам не ковырялся), правда вменяемой доки по использованию фрагментации я чтот не припомню.
dmz>Фрагментация только отсрочит смерть, на самом деле. Сделать по таблице на источник — это просто предельный случай фрагментации.
Поясни тогда, что по-твоему спасёт отца российской демократии? Есть что-то более эффективное чем шардинг?
К>Поясни тогда, что по-твоему спасёт отца российской демократии? Есть что-то более эффективное чем шардинг?
Меня беспокоит организация индексов при фрагментации. Т.е. я не понимаю как они там устроены, но если индексация сквозная по всем фрагментам, то время перестроения индексов при инсертах так и будет расти. Кроме того, пока не очень понятно, как например, в случае кластеризации намертво привязать user_id = сегмент_такой-то. Наверняка это делается, надо читать и смотреть.
В случае явной привязки мы убираем одно поле из индекса — чуть-чуть уменьшаем время перестроения индекса. Чуть-чуть быстрее будет делаться запрос, а специфика такова, что запросы из оперативной базы как раз выбирают данные только для одного user_id per запрос.
Упрощается майнтейнанс — т.е. все равно, что бы поддерживать данные в пределах, какие-то процессы должны будут прходить по таблице и убивать старые записи. В случае когда у нас 1 таблица — 1 пользователь, можно например майнтейнить таблицы для неактивных в данный момент пользователей, никак не влияя на работу остальных — ни блокировками, ни еще как.
Здравствуйте, dmz, Вы писали:
dmz>Какие минусы — ну кроме того, что это дурной тон и никто так не делает (в реляционных базах за такое убивают) ?
В яндексе например так делают. Правда с другими БД.
Да и вообще везде где нагрузка большая.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
dmz>>Какие минусы — ну кроме того, что это дурной тон и никто так не делает (в реляционных базах за такое убивают) ?
WH>В яндексе например так делают. Правда с другими БД. WH>Да и вообще везде где нагрузка большая.
Здравствуйте, dmz, Вы писали:
dmz>Прямо по таблице на пользователя?
По разному.
От некоторого фиксированного количества пользователей на таблицу. До базы данных (SQLite) на пользователя.
Зависит от задачи и результатов нагрузочного тестирования.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Всё есть.
