[программистское] high-performance in-memory db

[109]

интересная задачка, в кои-то веки. имеется база размером, который лезет в память (скажем, полгига). от которой требуются обычные датабазные операции, но очень быстро. точнее, запись можно не быстро, а вот чтение нужно быстро. просто кэшировать результаты запросов не получится, поскольку запросы представляют собой джойны 4-5 таблиц, 2-3 из которых реально большие.

кажется, что лучшим решением была бы какая-нибудь in-memory database. такие есть вообще? насколько скорость будет выше, чем если все эти таблицы создать в оракле с клаузой CACHE?

Comments

[vsi.livejournal.com]

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

[109.livejournal.com]

1. про скуль сервер речи ваще не шло :-)
2. по возможности он хранит и не только индексы
3. несмотря на наличие индексов, оптимизатор часто выбирает full scan, и тогда что есть индексы, что их нет...
4. лишние ненужные индексы засирают память, которая могла бы быть использована по прямому назначению

[vsi.livejournal.com]

1. скорее всего это будет работать не только со скуль сервером
2. к индексам у баз данных отношение совершенно особенное, они очень сильно старатются хранить их в памяти
3. оптимизатор не полезет в таблицу если все нужные колонки есть в индексах, он данные будет таскать прямо оттуда, в смысле из индексов
4. по прямому назначению это под memory disk? ;)

[109.livejournal.com]

3 - да нет же. если у тебя три условия на три разные колонки, то скорее всего будет full scan, несмотря на индексы.