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