[рассуждения] CMS:А если в RAM запихивать не всю таблицу, а только часть?
Как сейчас работает система:
1. делаю запрос данных
2. система смотрит: эта таблица должна быть в RAM?
- ДА: пытается загрузит ьданные из RAM, если данных нет, то восстанавливает данные в памяти
- НЕТ: запрос отправляется в БД
Но на практике зачастую есть проблема: часть данных нужны для быстрого чтения, а другая часть может быть громоздкой и к ней обращение идёт редко.
Т.е. для одной таблицы часть данных чтоит хранить в RAM, а часть - нет. Причём разделение стоит делать не по строкам, тк SELECT, например, выполняет операцию по всем столбцам. Т.е. разделение должно быть по столбцам.
Например, возьмём таблицу игр из стима (https://www.whoplay.ru ). Сейчас таблица содержит кучу данных, котоыре я гружу со стима + ещё будет добавлятсья описание текстовое и тп.
Но при кол-ве игр в 10 тыс или даже в 100 тыс мне надо ускорить фильтры и поиск по ним и их парамтерам. Я понимаю, например, что никто не будет искать игру по ссылке на сайт разработчика или по ссылке на самого разработчика/издателя. Никто точнон е будет искать игру по url картинке игры. Поэтмоу эти параметры я бы не запихивал в RAM. А останые стоит запихнуть, наприер жанр игры или локализация.
Вопрос с описание к игре спорный: с однйо стороны можно поиск сделать не толкьо по названию игры, но и по описанию ,если вбивают слово, которое характеризуцет игру, может быть совпадение. Но для этого есть умный поиск. Поэтмоу для малого кол-ва игр описание можно добавить в RAM, но почти во всех случаях не стоит такой фигнёй маиться.
К чем я веду: динамический контроль что записывать в RAM, а что нет имеет ряд неоспаримых плюсов. конечно, их можно обойти каждубю таблицу делить на ПАРАМЕТРЫ в RAM + остальные. Но это костыль. Нельзя будет без программирования менять хранить или не хранить в RAM столбец.
Попробую проанализировать поверхностно трудозатратность и объём по изменению архитектуры. Ес ть два варианта: хранить флаг подгрузки в рам внутри свойства или как отдельной таблицей:
1. каждый параметр должен иметь в БД дополнительное поле IsLoadOnRAM. Когда происходит первичная загрузка системы, часть Property со значениями должны грузиться в RAM.
2. сейчас чтобы таблица была в RAM, достаточно её добавить в список в специальную таблицу, которая нам сообщает что в RAM должно подгружаться.
Придётся добавить столбец "Property для загрузки в RAM", указывать список Property. Значит, и при удалении свойства и добавлении так же автоматом эту таблицу изменять.
Честно говоря, менять свтруктуру Property более тяжкая задача и не особо имеет смысл: где хранится свойство - это данные не свойства, а настроек свойства. Т.е. в будущем место хранения может иметь ещё пару доп мест: БД на SSD, БД на 7200p, БД на 5400р, RAM и тп. Т.е. 2 вариант более правильный и более лёгкий.
4. Логика запросов на уровне DBController.cs: Сейчас стоит флаг: если таблица есть в RAM, то запрос отправляется в RAM. Иначе SQL в БД.
Для каждого запроса придётся проверять наличие всех Property в запросе в RAM. Если хоть одно отсутвует в RAM, то запрос идёт в БД.
Для запросов с условиями: выпоняется через класс FilterEAV (класс для создания Expression к сущностям), где есть указанные idProperty, а значит, можно понять что в RAM.
Для костыльных запросов COMPLEX: это запросы к более чем одной таблице в рамках одной БД. Тут только БД.
5. Логика запросов на уровне DBController.cs: добавление, удаление, изменение и тп: выясняем, должен ли параметр быть в RAM?
- Функция IsMustPropertyOnRAM( idProperty ) // сначала смотрим, если таблица вообе в списке RAM. Если есть и есть такой idProperty, то TRUE. Иначе FALSE.
- Функция IsExpressionMustExecuteOnRAM( FilterEAV.Expression ) // Если в выражении все свойства в RAM, то выражение выполнять в RAM (то TRUE). Иначе FALSE.
1. делаю запрос данных
2. система смотрит: эта таблица должна быть в RAM?
- ДА: пытается загрузит ьданные из RAM, если данных нет, то восстанавливает данные в памяти
- НЕТ: запрос отправляется в БД
Но на практике зачастую есть проблема: часть данных нужны для быстрого чтения, а другая часть может быть громоздкой и к ней обращение идёт редко.
Т.е. для одной таблицы часть данных чтоит хранить в RAM, а часть - нет. Причём разделение стоит делать не по строкам, тк SELECT, например, выполняет операцию по всем столбцам. Т.е. разделение должно быть по столбцам.
Например, возьмём таблицу игр из стима (https://www.whoplay.ru ). Сейчас таблица содержит кучу данных, котоыре я гружу со стима + ещё будет добавлятсья описание текстовое и тп.
Но при кол-ве игр в 10 тыс или даже в 100 тыс мне надо ускорить фильтры и поиск по ним и их парамтерам. Я понимаю, например, что никто не будет искать игру по ссылке на сайт разработчика или по ссылке на самого разработчика/издателя. Никто точнон е будет искать игру по url картинке игры. Поэтмоу эти параметры я бы не запихивал в RAM. А останые стоит запихнуть, наприер жанр игры или локализация.
Вопрос с описание к игре спорный: с однйо стороны можно поиск сделать не толкьо по названию игры, но и по описанию ,если вбивают слово, которое характеризуцет игру, может быть совпадение. Но для этого есть умный поиск. Поэтмоу для малого кол-ва игр описание можно добавить в RAM, но почти во всех случаях не стоит такой фигнёй маиться.
К чем я веду: динамический контроль что записывать в RAM, а что нет имеет ряд неоспаримых плюсов. конечно, их можно обойти каждубю таблицу делить на ПАРАМЕТРЫ в RAM + остальные. Но это костыль. Нельзя будет без программирования менять хранить или не хранить в RAM столбец.
Попробую проанализировать поверхностно трудозатратность и объём по изменению архитектуры. Ес ть два варианта: хранить флаг подгрузки в рам внутри свойства или как отдельной таблицей:
1. каждый параметр должен иметь в БД дополнительное поле IsLoadOnRAM. Когда происходит первичная загрузка системы, часть Property со значениями должны грузиться в RAM.
2. сейчас чтобы таблица была в RAM, достаточно её добавить в список в специальную таблицу, которая нам сообщает что в RAM должно подгружаться.
Придётся добавить столбец "Property для загрузки в RAM", указывать список Property. Значит, и при удалении свойства и добавлении так же автоматом эту таблицу изменять.
Честно говоря, менять свтруктуру Property более тяжкая задача и не особо имеет смысл: где хранится свойство - это данные не свойства, а настроек свойства. Т.е. в будущем место хранения может иметь ещё пару доп мест: БД на SSD, БД на 7200p, БД на 5400р, RAM и тп. Т.е. 2 вариант более правильный и более лёгкий.
4. Логика запросов на уровне DBController.cs: Сейчас стоит флаг: если таблица есть в RAM, то запрос отправляется в RAM. Иначе SQL в БД.
Для каждого запроса придётся проверять наличие всех Property в запросе в RAM. Если хоть одно отсутвует в RAM, то запрос идёт в БД.
Для запросов с условиями: выпоняется через класс FilterEAV (класс для создания Expression к сущностям), где есть указанные idProperty, а значит, можно понять что в RAM.
Для костыльных запросов COMPLEX: это запросы к более чем одной таблице в рамках одной БД. Тут только БД.
5. Логика запросов на уровне DBController.cs: добавление, удаление, изменение и тп: выясняем, должен ли параметр быть в RAM?
- Функция IsMustPropertyOnRAM( idProperty ) // сначала смотрим, если таблица вообе в списке RAM. Если есть и есть такой idProperty, то TRUE. Иначе FALSE.
- Функция IsExpressionMustExecuteOnRAM( FilterEAV.Expression ) // Если в выражении все свойства в RAM, то выражение выполнять в RAM (то TRUE). Иначе FALSE.