посетил маленькую конференцию по low latency,
час говорили про IMDB, но не очень понятно как конкретно с этим работать, есть ли у кого-то практический опыт?

понятно что должно быть быстро и быстрее чем, скажем, объектный кэш (например oracle rdbms + coherence?), но есть несколько вопросов

1. что делать если данных больше чем памяти? у нас вроде на машинах памяти гига 64 оперативы, даже если предположить что всё уйдет под данные — не так уж и много, значит ли это что неизбежно нужно иметь ввиду распределенную бд? сколько обычно ставят оперативы под такие нужды?

2. даже если вся база в памяти, все равно необходим какой-то персистенс, если ежедневно все рестартить, не будет ли процесс загрузки данных в память занимать слишком много времени? там наверняка еще и индексы всякие етц?
как происходит изменение схемы, если скажем персисенс организован периодическими снэпшотами и логами транзакций, врядли будет также тривиально как в "обычной" бд?

спасибо

Здравствуйте, evgeny.e, Вы писали:

Автор этого блога (http://ayende.com/blog) сейчас разрабатывает IMDB на .net
с кодовым названием Voron. Он подробно делится всякими мелочами и вопросами дизайна.
Плюс делал code review других IMDB'шек (http://ayende.com/blog/tags/reviews).
Единственный минус -- у него в блоге все перемешано с постами об его (их) nosql
бд raven.

Здравствуйте, evgeny.e, Вы писали:

EE>понятно что должно быть быстро и быстрее чем, скажем, объектный кэш (например oracle rdbms + coherence?), но есть несколько вопросов

Почему Coherence будет медленнее IMDB? Oracle Coherence — это IMDB в общем смысле этого слова. Да, вместо SQL другой язык, но по функционалу и назначению это одно и тоже, IMHO. Oracle Database — это как раз тот persistance слой, про который вы говорите ниже. Выбрасываете его, и все будет работать так же быстро.

EE>1. что делать если данных больше чем памяти? у нас вроде на машинах памяти гига 64 оперативы, даже если предположить что всё уйдет под данные — не так уж и много, значит ли это что неизбежно нужно иметь ввиду распределенную бд? сколько обычно ставят оперативы под такие нужды?

Зависит от задач. Есть системы где в 1GB все умещается, есть кластера по 1.5TB общей памяти.

Тут еще не надо забывать про то, что данные в памяти могут занимать в 5-10 раз больше места, чем на диске. Плюс в распределенной системе нужно реплицировать данные несколько раз, чтобы отказ одного узла не приводил к глобальному сбою.

EE>2. даже если вся база в памяти, все равно необходим какой-то персистенс, если ежедневно все рестартить, не будет ли процесс загрузки данных в память занимать слишком много времени? там наверняка еще и индексы всякие етц?

1) Не обязательно все перезапускать каждый день. Есть системы 24x7...
2) В таких системах есть мягкий старт, когда все данные в память еще не загрузились, но пользоваться ими уже можно, так как сначала грузится карта хранения.
3) Индексы в памяти строятся очень быстро, это вообще не проблема.
4) low-latency — это ограниченный сегмент: банки, реклама, телеком. Железо можно купить хорошее -> скорость загрузки приемлимая.
5) Некоторые системы вообще живут без persistence. Зависит от бизнес области, но в случае может быть дешевле прекратить операции вообще и рестартовать в чистого листа.

EE>как происходит изменение схемы, если скажем персисенс организован периодическими снэпшотами и логами транзакций, врядли будет также тривиально как в "обычной" бд?
Современные БД работают с пулом страниц в памяти, к-ый по мере необходимости загружают/выгружают на диск. Так что persistence организован очень похожим образом: логи, снимки + логи, LSM + логи. Зависит от конфигурации и вендора.

я, честно говоря, просто не до конца понимаю что есть что, wiki говорит что coherence это in memory data grid, грид это то же что и database? а еще есть object cache (как например 2nd level cache в hibernate), что из этого лучше для чего? думаю вполне можно написать object cache так что произвольные запросы на нем будут быстро работать,
итого, что будет "быстрее", полноценная in-memory database, data grid или обычный object cache в который на старте помещено всё из БД

EE>>1. что делать если данных больше чем памяти? у нас вроде на машинах памяти гига 64 оперативы, даже если предположить что всё уйдет под данные — не так уж и много, значит ли это что неизбежно нужно иметь ввиду распределенную бд? сколько обычно ставят оперативы под такие нужды?

G>Зависит от задач. Есть системы где в 1GB все умещается, есть кластера по 1.5TB общей памяти.

G>Тут еще не надо забывать про то, что данные в памяти могут занимать в 5-10 раз больше места, чем на диске. Плюс в распределенной системе нужно реплицировать данные несколько раз, чтобы отказ одного узла не приводил к глобальному сбою.

дада, интересно с каким объемом памяти люди тут работают

G>1) Не обязательно все перезапускать каждый день. Есть системы 24x7...

есть, я не говорю что обязательно, но что если надо, если я правильно понимаю kdb кластер доступен постоянно, но непонятно, это штатный режим работы, и тогда особо не важно как персистенс организован, или просто один из вариантов, тогда интересно что делают в системах который перезагружаются каждый день

G>2) В таких системах есть мягкий старт, когда все данные в память еще не загрузились, но пользоваться ими уже можно, так как сначала грузится карта хранения.

мм данные не в памяти, а пользоваться можно? мягкий старт это интересно, надеюсь скорость загрузки там не превращает IMDB в бд с кэшем

EE>>как происходит изменение схемы, если скажем персисенс организован периодическими снэпшотами и логами транзакций, врядли будет также тривиально как в "обычной" бд?
G>Современные БД работают с пулом страниц в памяти, к-ый по мере необходимости загружают/выгружают на диск. Так что persistence организован очень похожим образом: логи, снимки + логи, LSM + логи. Зависит от конфигурации и вендора.

Обождите, если они на диск выгружаются, то это не IMDB а фигня какая-то, или вы не про них тут?
все равно механизм изменения схемы бд (скажем, перенос полей из одной таблицы в другую) не очень понятен

Здравствуйте, evgeny.e, Вы писали:

EE>итого, что будет "быстрее", полноценная in-memory database, data grid или обычный object cache в который на старте помещено всё из БД
Невозможно сказать что будет быстрее для абстрактной задачи. На оптимальное решение влияют 10-ки факторов значительная часть из которых вообще не технического характера.

G>>2) В таких системах есть мягкий старт, когда все данные в память еще не загрузились, но пользоваться ими уже можно, так как сначала грузится карта хранения.
EE>мм данные не в памяти, а пользоваться можно? мягкий старт это интересно, надеюсь скорость загрузки там не превращает IMDB в бд с кэшем
Да, производительность во время мягкого старта сравнимая с обыкновенной БД.

EE>>>как происходит изменение схемы, если скажем персисенс организован периодическими снэпшотами и логами транзакций, врядли будет также тривиально как в "обычной" бд?
G>>Современные БД работают с пулом страниц в памяти, к-ый по мере необходимости загружают/выгружают на диск. Так что persistence организован очень похожим образом: логи, снимки + логи, LSM + логи. Зависит от конфигурации и вендора.

EE>Обождите, если они на диск выгружаются, то это не IMDB а фигня какая-то, или вы не про них тут?
EE>все равно механизм изменения схемы бд (скажем, перенос полей из одной таблицы в другую) не очень понятен
Я говорил про "обычные", не In-Memory DB. Механизмы persistent везде одинаковые.

In-Memory Whatever Product — это всегда операционный view, каких-то других "нормативных" данных. Который создается/воссоздается при старте системы.

Здравствуйте, evgeny.e, Вы писали:

EE>дада, интересно с каким объемом памяти люди тут работают
SAP HANA 100 TB performance test
З. Ы. Но это скорее там, чем тут.