[СУБД] "Максимум данных надо хранить в оперативке"
> Оцените адекватность этого утверждения, пожалуйтса.
> Особенно интересуют аргументированные ответы.
Просьба звучит по-идиотски. Посмотри в словарь и узнай, что
адекватность не может висеть в воздухе, она должна быть отнесена
к чему-либо. Вот в зависимости от этого "чего-либо", утверждение
может быть как полностью адекватным, так и совсем неадекватным.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> Особенно интересуют аргументированные ответы.
Просьба звучит по-идиотски. Посмотри в словарь и узнай, что
адекватность не может висеть в воздухе, она должна быть отнесена
к чему-либо. Вот в зависимости от этого "чего-либо", утверждение
может быть как полностью адекватным, так и совсем неадекватным.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
даже если у локальной БД используется кеширование запросов, она ответит медленнее памяти - издержки на подключение и парсинг ответа
"максимум данных надо хранить в оперативке" оно и логично - скорость доступа к данным в оперативке куда выше чем к данным где-либо ещё
ну это так, чисто интуитивно
"максимум данных надо хранить в оперативке" оно и логично - скорость доступа к данным в оперативке куда выше чем к данным где-либо ещё
ну это так, чисто интуитивно
учитывая то, что бывают инмемори субд, то тут явно путают теплое с мягким
Интуитивно-то это очевидно, но как быть если данные и читаются, и пишутся? В этом случае нужно решать вопросы синхронизации, и сомневаюсь, что решить их не хуже разработчиков какой-нибудь распространённой СУБД просто.
thread, lock, google
Интуитивно-то это очевидно, но как быть если данные и читаются, и пишутся?значит хранить в памяти, в первую очередь, ту часть данных, которая меняется редко
Но так все это мне в целом напоминает:
Оцените адекватность совета "мойте руки перед едой".
у меня есть сомнения в полезности этого совета, т.к. я не понимаю, как это можно сделать - если приходиться есть на морозе в -50 градусов.
ps
если серьезно: да, по жизни есть много разных рекомендаций, да эти рекомендации работают не при всех условиях, но это не означает что рекомендации бесполезны или неадекватны, это лишь означает что в каждом конкретном случае - часть рекомендаций стоит применить, а часть придеться откинуть.
Оцените адекватность совета "мойте руки перед едой".
у меня есть сомнения в полезности этого совета, т.к. я не понимаю, как это можно сделать - если приходиться есть на морозе в -50 градусов.
ps
если серьезно: да, по жизни есть много разных рекомендаций, да эти рекомендации работают не при всех условиях, но это не означает что рекомендации бесполезны или неадекватны, это лишь означает что в каждом конкретном случае - часть рекомендаций стоит применить, а часть придеться откинуть.
> "максимум данных надо хранить в оперативке" оно и логично
Ну вот, например, случилось несчастье, умер процесс.
Соответственно, ОС память затёрла и перераспределила.
И нет твоих данных, которые ты там хранил.
---
"Значение болевого импульса в нашей жизни неоценимо!"
Ну вот, например, случилось несчастье, умер процесс.
Соответственно, ОС память затёрла и перераспределила.
И нет твоих данных, которые ты там хранил.
---
"Значение болевого импульса в нашей жизни неоценимо!"
Ну вот, например, случилось несчастье, умер процесс.ну вот, например, случилось несчастье, произошел ядерный взрыв.
Соответственно, ОС память затёрла и перераспределила.
И нет твоих данных, которые ты там хранил.
Соответственно, взрывная волна все затерла и перераспределила.
и нет твоих данных, которые ты там хранил.
ps
база данных сама по себе никаких особых гарантий по сравнению с памятью не дает.
и в том, и в другом случае - все равно надо думать головой что и зачем сохраняется, все равно надо помнить, что несчастья случаются, все равно надо считать вероятности, делать backup-ы, разбираться с длительностью хранения и т.д.
> база данных сама по себе никаких особых гарантий по сравнению
> с памятью не дает.
Это ты так думаешь, а на практике получается иначе.
Разумеется, этого в книжках по C# не написано.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> с памятью не дает.
Это ты так думаешь, а на практике получается иначе.
Разумеется, этого в книжках по C# не написано.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Ну тогда конкретизуем. Утверждение было высказано в процессе обсуждения следующей ситуации:
Есть довольно большая таблица, хранящая дерево. Для простоты предположим, что она состоит из двух полей ID и ParentID. Сейчас из её данных в памяти Web-приложения (серверная сторона, разумеется) строится дерево за десяток секунд, которое затем многократно используется при чтении данных.
При этом структура дерева изредка меняется. Надо обновлять кеш, но тут появляются проблемы синхронизации.
Есть довольно большая таблица, хранящая дерево. Для простоты предположим, что она состоит из двух полей ID и ParentID. Сейчас из её данных в памяти Web-приложения (серверная сторона, разумеется) строится дерево за десяток секунд, которое затем многократно используется при чтении данных.
При этом структура дерева изредка меняется. Надо обновлять кеш, но тут появляются проблемы синхронизации.
Сейчас из её данных в памяти Web-приложения (серверная сторона, разумеется) строится дерево за десяток секундКласс! А почему не 0.1 с? Только не говорите мне, что делается более 1000 запросов к БД!
Я ещё не смотрел код.
Вообще я тоже офигел.
Предлагаю рассмотреть гипотетическую ситуацию, что быстрее пострить не получится. Иначе уже совсем другой вопрос будет, который я и сам в состоянии решить.
Вообще я тоже офигел.
Предлагаю рассмотреть гипотетическую ситуацию, что быстрее пострить не получится. Иначе уже совсем другой вопрос будет, который я и сам в состоянии решить.
Тут имеет место быть банальный мемори-цпу трейдофф. Все зависит от специфики.
Смотрите, сколько весит ваше дерево в памяти.
Оцениваете/замеряете, насколько станет тормознутее приложение, если у него "отобрать" эту память.
Из полученного времени вычитаете выигрыш от хранения готового дерева в памяти. Если результат отрицательный => смысл имеет.
Кэш либов сейчас полно везде. Проблемы синхронизации там так или иначе решаются без вашего участия.
При желании - бывают дистрибьютед кеши aka IMDG. Их поменьше, но тоже хватает.
Приличные средства доступа к бд умеют этими кешами пользоваться. В этом варианте вам достаточно подружить ваше средство доступа к БД и кеш, и при некоторой удаче даже код менять не придется.
Если же хочется жестко все контролировать (читай быть 100% уверенным, что в кеше всегда есть это дерево) - кладите свое построенное дерево в кеш руками, только рефрешить(но не синхронизировать) кеш придется самостоятельно.
В конце концов, раз дерево меняется редко, то можно синхронизацию и руками написать, ничего там страшного не будет. Как реализовать модель типа один-писатель/много-читателей - полно описалова. Думаю, вам она подойдет.
Смотрите, сколько весит ваше дерево в памяти.
Оцениваете/замеряете, насколько станет тормознутее приложение, если у него "отобрать" эту память.
Из полученного времени вычитаете выигрыш от хранения готового дерева в памяти. Если результат отрицательный => смысл имеет.
Кэш либов сейчас полно везде. Проблемы синхронизации там так или иначе решаются без вашего участия.
При желании - бывают дистрибьютед кеши aka IMDG. Их поменьше, но тоже хватает.
Приличные средства доступа к бд умеют этими кешами пользоваться. В этом варианте вам достаточно подружить ваше средство доступа к БД и кеш, и при некоторой удаче даже код менять не придется.
Если же хочется жестко все контролировать (читай быть 100% уверенным, что в кеше всегда есть это дерево) - кладите свое построенное дерево в кеш руками, только рефрешить(но не синхронизировать) кеш придется самостоятельно.
В конце концов, раз дерево меняется редко, то можно синхронизацию и руками написать, ничего там страшного не будет. Как реализовать модель типа один-писатель/много-читателей - полно описалова. Думаю, вам она подойдет.
Ну вот, например, случилось несчастье, умер процесс.Это не проблема. У нас все данные за день хранятся в памяти, тем не менее, самая распространенная проблема - это не падение процесса (случалось может пару раз в год а разрыв соединения с источником данных.
Соответственно, ОС память затёрла и перераспределила.
И нет твоих данных, которые ты там хранил.
Класс! А почему не 0.1 с? Только не говорите мне, что делается более 1000 запросов к БД!там же не написано количество данных, откуда твои числа взялись?
> самая распространенная проблема - это не падение процесса
> (случалось может пару раз в год а разрыв соединения с
> источником данных.
Если хранить WAL на этом же узле, то это становится больше похоже
на локальную СУБД, синхронизирующуюся с основной.
---
...Я работаю антинаучным аферистом...
> (случалось может пару раз в год а разрыв соединения с
> источником данных.
Если хранить WAL на этом же узле, то это становится больше похоже
на локальную СУБД, синхронизирующуюся с основной.
---
...Я работаю антинаучным аферистом...
Если база предназначена для записи, а не для чтения, то вопрос становится вообще бессмысленным 
- что бы ты не хранил в оперативке, оно все равно не понадобится.
- что бы ты не хранил в оперативке, оно все равно не понадобится.Оставить комментарий
agaaaa
Оцените адекватность этого утверждения, пожалуйтса. Особенно интересуют аргументированные ответы.