Comments 56
Почему не рассматривали HP Vertica?
1) Не пробовали Apache Kudu?
2) Есть данные по сравнительной стоимости систем?
2) Есть данные по сравнительной стоимости систем?
1) Нет, узнал о проекте от Вас :) Почитал кратко — проект интересный. Однако, пока настораживают:
— ограниченная поддержка timestamp и decimal
— необходимость наличия Импалы
Что радует, изначально заложена правильная дистрибюция таблиц по интервалу поля/полей.
2) Есть, но рассказать, увы, не смогу. Могу только сказать, что примерно затраты пропорциональны результатам теста производительности в статье :)
— ограниченная поддержка timestamp и decimal
— необходимость наличия Импалы
Что радует, изначально заложена правильная дистрибюция таблиц по интервалу поля/полей.
2) Есть, но рассказать, увы, не смогу. Могу только сказать, что примерно затраты пропорциональны результатам теста производительности в статье :)
Рекомендую подробней почитать по Kudu — по моему мнению это очень стоящее решение, остслось дождаться пока его допилят до production ready состояния.
По затратам — может ли так оказатсья что бесплатная импала за те же деньги (больше желелаз) будет шустрее экзасола?
Еще вопрос по статье: есть ли возможность еще протестировать последнюю версию MemSQL? Заявлено значительное повышение производительности.
По затратам — может ли так оказатсья что бесплатная импала за те же деньги (больше желелаз) будет шустрее экзасола?
Еще вопрос по статье: есть ли возможность еще протестировать последнюю версию MemSQL? Заявлено значительное повышение производительности.
Про затраты: да, несмотря на 7-ми кратное преимущество в скорости, можно добиться преимущества покупкой большего числа серверов за те же деньги. Однако нужно помнить, что:
— большее число серверов влечёт за собой бОльшие накладные расходы в кластере;
— возрастает сложность поддержки и администрирования;
— ЦОД не резиновый и тд и тп.
Да и помимо скорости есть и другие параметры, надо оценивать всё в сумме.
Про MemSQL — блин, как вовремя они подсуетились :( Новая версия (5.5, релиз 03.10.2016) обещает "...a new hash table design which combined with Bloom filters delivers up to 3x-5x performance improvements for hash joins".
Сейчас стенды уже разобрали, протестировать не сможем.
— большее число серверов влечёт за собой бОльшие накладные расходы в кластере;
— возрастает сложность поддержки и администрирования;
— ЦОД не резиновый и тд и тп.
Да и помимо скорости есть и другие параметры, надо оценивать всё в сумме.
Про MemSQL — блин, как вовремя они подсуетились :( Новая версия (5.5, релиз 03.10.2016) обещает "...a new hash table design which combined with Bloom filters delivers up to 3x-5x performance improvements for hash joins".
Сейчас стенды уже разобрали, протестировать не сможем.
Вот, если интересно, бенчмарк Kudu vs Impala/Parquet (правда, старый)
http://www.slideshare.net/cloudera/kudu-new-hadoop-storage-for-fast-analytics-on-fast-data/40
http://www.slideshare.net/cloudera/kudu-new-hadoop-storage-for-fast-analytics-on-fast-data/40
Продолжу тренд «А не пробовали ?»
А не смотрели http://www.aerospike.com?
Пока что встречал — все хвалили на Хабре.
А не смотрели http://www.aerospike.com?
Пока что встречал — все хвалили на Хабре.
Парни, привет, отличная статья!
Удивил фидбек по SAP HANA — ожидал от нее большего.
Кстати, почти все сравниваемые СУБД — не особо In-memory.
Кэширование блоков данных(причем на уровне ОС) != in-memory DBMS. Нет гарантий того, откуда эти данные берутся(диск/кеш), что с ними происходит и когда они вывалятся из кэша.
На мой взгляд критерий column-oriented был слишком строгим — можно было попробовать VoltDB например.
Так же не понятно, сколько раз запускался каждый запрос? Exasol умеет умеет оптимизировать запросы и среднее время запуска у него может сильно отличаться от времени первого выполнения.
Что в итоге-то выбрали?
Удивил фидбек по SAP HANA — ожидал от нее большего.
Кстати, почти все сравниваемые СУБД — не особо In-memory.
Кэширование блоков данных(причем на уровне ОС) != in-memory DBMS. Нет гарантий того, откуда эти данные берутся(диск/кеш), что с ними происходит и когда они вывалятся из кэша.
На мой взгляд критерий column-oriented был слишком строгим — можно было попробовать VoltDB например.
Так же не понятно, сколько раз запускался каждый запрос? Exasol умеет умеет оптимизировать запросы и среднее время запуска у него может сильно отличаться от времени первого выполнения.
Что в итоге-то выбрали?
Привет, спасибо!
Про не-in-memory — отчасти согласен, GP и Impala — не in-memory-решения, о чём и упомянул в статье. memSQL и HANA — классические in-memory, memSQL, например, при запуске загружает с диска вообще всё в память и работает только с ней. C Exasol и Clickhouse уже зависит от точки зрения :)
Про VoltDB — изначально рассматривали, однако это не совсем SQL-совместимая БД, с этим скорее всего будут сложности — нам нужна прозрачная интеграция с SAP BO. Кроме того, она и не позиционируется как аналитическая (выросла из H-Store, что есть OLTP-решение).
Про число запусков тестовых запросов: везде бралось первое выполнение запроса, при этом экспериментально выяснили, что первое и второе выполнения по времени значительно отличаются только у Exasol — второй раз он отрабатывает значительно быстрее за счёт построенных при первом запуске индексов (впрочем даже время первого выполнения в Exasol всегда значительно меньше, чем второго всех остальных баз). Пример:
Запрос 1-ый 2-ой
T1 1.8 0.1
T2 4.2 0.1
Правильней, конечно же, было выполнить каждый запрос 5-10 раз, отбросить лучшее и худшее и взять среднее от оставшегося, однако тогда тестирование бы затянулось. Кроме того, так как мы рассчитываем на этой базе выполнять в том числе и ad-hoc запросы пользователей, время первого выполнения нам интересней.
Про не-in-memory — отчасти согласен, GP и Impala — не in-memory-решения, о чём и упомянул в статье. memSQL и HANA — классические in-memory, memSQL, например, при запуске загружает с диска вообще всё в память и работает только с ней. C Exasol и Clickhouse уже зависит от точки зрения :)
Про VoltDB — изначально рассматривали, однако это не совсем SQL-совместимая БД, с этим скорее всего будут сложности — нам нужна прозрачная интеграция с SAP BO. Кроме того, она и не позиционируется как аналитическая (выросла из H-Store, что есть OLTP-решение).
Про число запусков тестовых запросов: везде бралось первое выполнение запроса, при этом экспериментально выяснили, что первое и второе выполнения по времени значительно отличаются только у Exasol — второй раз он отрабатывает значительно быстрее за счёт построенных при первом запуске индексов (впрочем даже время первого выполнения в Exasol всегда значительно меньше, чем второго всех остальных баз). Пример:
Запрос 1-ый 2-ой
T1 1.8 0.1
T2 4.2 0.1
Правильней, конечно же, было выполнить каждый запрос 5-10 раз, отбросить лучшее и худшее и взять среднее от оставшегося, однако тогда тестирование бы затянулось. Кроме того, так как мы рассчитываем на этой базе выполнять в том числе и ad-hoc запросы пользователей, время первого выполнения нам интересней.
Немного мыслей по тестированию.
1) Хорошо бы использовать более мощные физические серверы, если есть возможность их собрать. Особенно в плане памяти, 128Gb маловато уже.
2) Побольше бы данных. 500 миллионов для современных СУБД — на один зуб. Миллиардах на десяти разница между решениями куда более существенная. Bottleneck'и лучше видно.
3) Пример D2 очень хороший. И даже не тем, что сразу несколько колонок используется, а тем, что он заставляет СУБД разжимать значения и вычислять результат отдельно для каждого ряда. «Волшебная оптимизиация» перестаёт работать, и можно увидеть реалистичные результаты. Многие решения этот тест проваливают.
Другой вариант этого теста — сложный LIKE:
4) По-возможности, даты лучше вычислять в скрипте и передавать в запросы в готовом виде. Например:
заменить на:
Сейчас всё больше решений могут использовать такие простые фильтры, чтобы читать меньше данных и ускорить выполнение запросов в разы. Грех не пользоваться.
1) Хорошо бы использовать более мощные физические серверы, если есть возможность их собрать. Особенно в плане памяти, 128Gb маловато уже.
2) Побольше бы данных. 500 миллионов для современных СУБД — на один зуб. Миллиардах на десяти разница между решениями куда более существенная. Bottleneck'и лучше видно.
3) Пример D2 очень хороший. И даже не тем, что сразу несколько колонок используется, а тем, что он заставляет СУБД разжимать значения и вычислять результат отдельно для каждого ряда. «Волшебная оптимизиация» перестаёт работать, и можно увидеть реалистичные результаты. Многие решения этот тест проваливают.
Другой вариант этого теста — сложный LIKE:
WHERE foo LIKE '%' || bar || '%'
4) По-возможности, даты лучше вычислять в скрипте и передавать в запросы в готовом виде. Например:
to_date(( 2016 - 2)::character varying ||'-01-01', 'YYYY-MM-DD')
заменить на:
'2014-01-01'
Сейчас всё больше решений могут использовать такие простые фильтры, чтобы читать меньше данных и ускорить выполнение запросов в разы. Грех не пользоваться.
+1 в «А не пробовали ?»: Kognitio
Это самая настоящая in-memory БД. То есть, данные там действительно должны влезать в физическую память, иначе она отказывается работать. Никаких индексов, все брутальный и быстрый фулл скан. По нашим оценкам, они превосходили скорость Exasolа в несколько раз. Но не скоростью единой живет человек, да и цена у них тоже сильно кусачая была, поэтому в итоге выбрали не их. Но если вам нужна как раз скорость, объем Data Warehouse не будет превосходить нескольких TB, и цена для вас не вопрос, то я бы рекомендовал присмотреться. У нас главным блокером был как раз фактор быстрого роста данных.
Это самая настоящая in-memory БД. То есть, данные там действительно должны влезать в физическую память, иначе она отказывается работать. Никаких индексов, все брутальный и быстрый фулл скан. По нашим оценкам, они превосходили скорость Exasolа в несколько раз. Но не скоростью единой живет человек, да и цена у них тоже сильно кусачая была, поэтому в итоге выбрали не их. Но если вам нужна как раз скорость, объем Data Warehouse не будет превосходить нескольких TB, и цена для вас не вопрос, то я бы рекомендовал присмотреться. У нас главным блокером был как раз фактор быстрого роста данных.
Спасибо, выглядит интересно. Странно, что про неё так мало информации. А вы её сравнивали с Exasol вживую?
Да, 3 дня делали POC на их кластере с 20-ью нодами. Тестировали те же запросы и на тех же данных, что и для Exasola.
Чуть побольше расскажу про Kognitio. Их главная проблема — rows based storage. Из-за этого намного хуже ситуация с компрессией и оптимизацией count\sum\аналитики. Но, если данные целиком влезают в память, то всё очень быстро.
У пользователя есть полный контроль над тем, что находится в памяти. Можно создавать проекции или какие-то определённые sub-set'ы и хранить их только in-memory, не дублируя данные на дисках. Есть богатые возможности и почти полный контроль над distribution данных по нодам.
У них очень хороший loader, прекрасный EXPLAIN (аж трёх видов), и вообще в целом качество софта производит отличное впечатление.
Минусы СУБД:
1) Меньше подходит для ad-hoc запросов.
2) Очень критична к количеству памяти.
3) Нужно больше железа, чем на Exasol.
4) Дорого (на мой взгляд, по состоянию 2-3 года назад).
У пользователя есть полный контроль над тем, что находится в памяти. Можно создавать проекции или какие-то определённые sub-set'ы и хранить их только in-memory, не дублируя данные на дисках. Есть богатые возможности и почти полный контроль над distribution данных по нодам.
У них очень хороший loader, прекрасный EXPLAIN (аж трёх видов), и вообще в целом качество софта производит отличное впечатление.
Минусы СУБД:
1) Меньше подходит для ad-hoc запросов.
2) Очень критична к количеству памяти.
3) Нужно больше железа, чем на Exasol.
4) Дорого (на мой взгляд, по состоянию 2-3 года назад).
Во, а подскажите какую-то легковесную in-memory non-SQL DB, чтобы использовать в JS приложении (не веб)? Можно конечно Mongo, но хочется in-memory.
А не пробовали GridGain?
за счёт свойств XFS
Пробовали ли смотреть на ZFS? У него также довольно сильное кеширование (ARC, L2ARC).
Потрясающая статья, больше спасибо!
Не могли бы вы рассказать, в чем именно заключаются преимущества развертывания PostgreSQL / Greenplum именно на XFS, а не на EXT4?
Не могли бы вы рассказать, в чем именно заключаются преимущества развертывания PostgreSQL / Greenplum именно на XFS, а не на EXT4?
Спасибо!
Про преимущества той или иной ФС для GP не могу сказать, подробно не изучал вопрос (полагался на вендора:) ). Однако, в моём комментарии выше я был немного неправ, ZFS поддерживается для GP on Solaris.
Вот тут немного информации о ZFS <> XFS для GP:
https://discuss.pivotal.io/hc/en-us/community/posts/200796448-Solaris-ZFS-v-Linux-XFS
Про преимущества той или иной ФС для GP не могу сказать, подробно не изучал вопрос (полагался на вендора:) ). Однако, в моём комментарии выше я был немного неправ, ZFS поддерживается для GP on Solaris.
Вот тут немного информации о ZFS <> XFS для GP:
https://discuss.pivotal.io/hc/en-us/community/posts/200796448-Solaris-ZFS-v-Linux-XFS
XFS хорошо работает с большими «блоками» данных и не вызывает фрагментации, что для аналитических СУБД и последовательного чтения очень полезно.
Данные для тестов где-то можно взять?
Я тогда обязуюсь протестирвать Azure Datawarehouse и SQL Server (таблицы в inmemory)
Я тогда обязуюсь протестирвать Azure Datawarehouse и SQL Server (таблицы в inmemory)
Увы, выложить данные не можем, среди них есть персональные данные :(
Можно было бы деперсонализировать. Просим, просим))
Жалко… Тем более что инженерам HANA вы такой доступ предоставили :(
Сколько нод вы использовали для GreenPlum и для Exasol?
Присоеденяюсь с к просьбе Обесличивания баз данных… По идее это только номера счетов
Сколько нод вы использовали для GreenPlum и для Exasol?
Присоеденяюсь с к просьбе Обесличивания баз данных… По идее это только номера счетов
Инженеры HANA проводили тестирование на нашем железе, да и некие официальные договорённости у нас с ними есть (сотрудничаем с этой компанией и по другому софту SAP).
Про деперсонализацию — обещаю в ближайшее время проработать вопрос (нужно согласие руководства + оценить объём работ по деперсонализации, там не только номера счетов), напишу в личку заинтересовавшимся :)
Про деперсонализацию — обещаю в ближайшее время проработать вопрос (нужно согласие руководства + оценить объём работ по деперсонализации, там не только номера счетов), напишу в личку заинтересовавшимся :)
ЭТо бы было крайне любопытно.
Как раз сейчас идет обсуждение подобного теста на sql.ru (http://www.sql.ru/forum/1222372/agregaciya-dannyh-100-mln-strok)
А я недавно проводил тестирование на по такой методологии: https://db.in.tum.de/research/projects/CHbenCHmark/?lang=en
На таких платформах:
HANA
Oracle 12.x
DB2-10.5(blue)
Memsql
Posgresql (9.6 betta)
SQL Server 2016
Данных было чуть поменьше, чем у вас…
Но запросов побольше (22)
SQL server был лучшим в этом сравнении… все 22 запроса выполнились за час более 50 раз.
Второй, кстати была HANA
К примеру, Posgresql не успел выполнить все эти запросы за час дважды.
Сами данные, если кому интересно можно найти здесь:
https://northcentr.blob.core.windows.net/tpcc/customer.txt 9g
https://northcentr.blob.core.windows.net/tpcc/district.txt 1m
https://northcentr.blob.core.windows.net/tpcc/history.txt 1g
https://northcentr.blob.core.windows.net/tpcc/item.txt 8m
https://northcentr.blob.core.windows.net/tpcc/nation.txt 10kb
https://northcentr.blob.core.windows.net/tpcc/order_line.txt 9g
https://northcentr.blob.core.windows.net/tpcc/orders.txt 1g
https://northcentr.blob.core.windows.net/tpcc/region.txt .5m
https://northcentr.blob.core.windows.net/tpcc/stock.txt 14g
https://northcentr.blob.core.windows.net/tpcc/supplier.txt 2mb
https://northcentr.blob.core.windows.net/tpcc/warehouse.txt 40kb
Как раз сейчас идет обсуждение подобного теста на sql.ru (http://www.sql.ru/forum/1222372/agregaciya-dannyh-100-mln-strok)
А я недавно проводил тестирование на по такой методологии: https://db.in.tum.de/research/projects/CHbenCHmark/?lang=en
На таких платформах:
HANA
Oracle 12.x
DB2-10.5(blue)
Memsql
Posgresql (9.6 betta)
SQL Server 2016
Данных было чуть поменьше, чем у вас…
Но запросов побольше (22)
SQL server был лучшим в этом сравнении… все 22 запроса выполнились за час более 50 раз.
Второй, кстати была HANA
К примеру, Posgresql не успел выполнить все эти запросы за час дважды.
Сами данные, если кому интересно можно найти здесь:
https://northcentr.blob.core.windows.net/tpcc/customer.txt 9g
https://northcentr.blob.core.windows.net/tpcc/district.txt 1m
https://northcentr.blob.core.windows.net/tpcc/history.txt 1g
https://northcentr.blob.core.windows.net/tpcc/item.txt 8m
https://northcentr.blob.core.windows.net/tpcc/nation.txt 10kb
https://northcentr.blob.core.windows.net/tpcc/order_line.txt 9g
https://northcentr.blob.core.windows.net/tpcc/orders.txt 1g
https://northcentr.blob.core.windows.net/tpcc/region.txt .5m
https://northcentr.blob.core.windows.net/tpcc/stock.txt 14g
https://northcentr.blob.core.windows.net/tpcc/supplier.txt 2mb
https://northcentr.blob.core.windows.net/tpcc/warehouse.txt 40kb
Я тут сервер подготовил.
Есть шансы на данные?
Есть шансы на данные?
— Какую версию MemSQL вы использовали? В версии 5.5 аналитические запросы намного быстрее?
— Какой размер кластера?
— RowStore или Columnstore
— Что использовали вместо DATE_TRUNC?
— Какой размер кластера?
— RowStore или Columnstore
— Что использовали вместо DATE_TRUNC?
1) Версии указаны в статье в таблице. Memsql — 5.1.0. Версию 5.5 не тестировали, она вышла уже после завершения тестирования, когда машины у нас забрали.
2) Характеристики машин указаны в начале статьи (две машины на каждую БД).
3) Везде, где возможно, использовали Columnstore.
4) Использовали MONTH() и YEAR().
2) Характеристики машин указаны в начале статьи (две машины на каждую БД).
3) Везде, где возможно, использовали Columnstore.
4) Использовали MONTH() и YEAR().
MemSQL не основан на MySQL, как написано в статье, а совершенно независимая и проприетарная СУБД, совместимая с MySQL по протоколу. Две большие разницы, как по мне.
Интересно. Можете привести данные, которые это доказывают? Действительно, нигде в документации прямо не указывается о наследовании, но это и не опровергается (не нашёл, по крайней мере).
Да я даже не знаю, с чего начинать. Наверное, с того, что MemSQL построен на совершенно других концепциях, чем MySQL или другие популярные РСУБД. Единственная совместимость с MySQL, которую обещают — это клиент-серверный протокол. Ни совместимости по файлам данных, ни по функциональности между MySQL и MemSQL нет и никогда не было. Я собственно впервые слышу версию о том, что MemSQL основан на MySQL. Откуда такая информация?
Спасибо за статью, все четко и без воды!
Я не специалист в In-Memory и пока верю в старый добрый Оракл, возможно еще рано списывать старичка со счетов. В 12 версии появилась опция по сути превращающая базу данных в In-Memory. Хотелось бы где ни будь увидеть тестирование этой опции с SAP HANA например. Все таки sql оптимизатор Оракла очень хорошо прописан и оптимизирован, думаю он еще долго будет давать фору. Правда ни поколоночного хранения в Оракле нет, только в версии Exadata и только в сжатых данных. Ни добавления кластера нет, но сейчас можно собрать сервер с 2-4 Тб оперативной памяти, что можно быть достаточно для ваших нужд.
Я не специалист в In-Memory и пока верю в старый добрый Оракл, возможно еще рано списывать старичка со счетов. В 12 версии появилась опция по сути превращающая базу данных в In-Memory. Хотелось бы где ни будь увидеть тестирование этой опции с SAP HANA например. Все таки sql оптимизатор Оракла очень хорошо прописан и оптимизирован, думаю он еще долго будет давать фору. Правда ни поколоночного хранения в Оракле нет, только в версии Exadata и только в сжатых данных. Ни добавления кластера нет, но сейчас можно собрать сервер с 2-4 Тб оперативной памяти, что можно быть достаточно для ваших нужд.
Спасибо, статья действительно очень интересная.
А почему не тестировались CitusDB (в отличие от GreenPlum ставится поверх Postgres, то есть работает на свежих версиях, а не 8.4) и monetdb?
А почему не тестировались CitusDB (в отличие от GreenPlum ставится поверх Postgres, то есть работает на свежих версиях, а не 8.4) и monetdb?
У CitusDB нет более-менее эффективных произвольных JOIN'ов. Хотят видеть только JOIN по одинаковым распределённым ключам.
У monetdb и его последователя VectorWise всё неплохо, но нет нормального шардинга. Есть только REMOTE TABLE. После того, как упираешься в мощность одной ноды, наступает беда.
У monetdb и его последователя VectorWise всё неплохо, но нет нормального шардинга. Есть только REMOTE TABLE. После того, как упираешься в мощность одной ноды, наступает беда.
У CitusDB нет более-менее эффективных произвольных JOIN'ов. Хотят видеть только JOIN по одинаковым распределённым ключам.
Простите, что значит нет?
Ещё с версии 4.х эквиджойны есть для любых таблиц:
CitusDB supports equi-JOINs between any number of tables irrespective of their size and distribution method. The query planner chooses the optimal join method and join order based on the statistics gathered from the distributed tables. It evaluates several possible join orders and creates a join plan which requires minimum data to be transferred across network.
Или вы имеете ввиду что работают они медленно и оптимизатор плохо справляется с локальностью данных?
Да, прошу прощения, но всё-таки очень хочется спросить ещё про In-Memory-Data-Grid, или In-Memory-SQL-Grid. Вы их рассматривали? В частности, например проект apache ignite предоставляет не только программный интерфейс в стиле Data Grid computing, но обещают прямо ANSI SQL-99 совместимость и стандартный JDBC доступ.
Очень интересно ваше мнение по этому поводу.
Очень интересно ваше мнение по этому поводу.
Коллеги, подскажите, пожалуйста, насколько сейчас актуальны замечания о функциональности ClickHouse?
И, вообще, если про аналитику говорить
, то что в 2020(1) стоит рассматривать?
И, вообще, если про аналитику говорить
- не только in-memory
- но с хорошей поддержкой SQL
- ну и, пожалуй, колоночную
- данные не обновляются
- при прочих примерно равных выбираем архитектуру проще
, то что в 2020(1) стоит рассматривать?
- десятки колонок, миллиарды строк
- крайне редкие, но объемные запросы
- скорее один сервер, нежели кластер
Спасибо!
По состоянию на 2020, ClickHouse — непревзойдённое решение на таком сценарии.
Рекомендую посмотреть статью — демо работы ClickHouse на одном сервере на данных событий GitHub: gh.clickhouse.tech/explorer
Там же можно нажать на карандашик и повыполнять разные запросы в реальном времени.
Рекомендую посмотреть статью — демо работы ClickHouse на одном сервере на данных событий GitHub: gh.clickhouse.tech/explorer
Там же можно нажать на карандашик и повыполнять разные запросы в реальном времени.
> поддерживается только JOIN с подзапросом в качестве правой части;
Теперь поддерживаются не только такие виды JOIN.
> условия в join-е не пробрасываются внутрь подзапроса;
Теперь пробрасываются. (За исключением некоторых случаев — например, в правую часть LEFT JOIN).
> распределённые join-ы выполняются неэффективно.
В некоторой мере осталось так же.
Теперь поддерживаются не только такие виды JOIN.
> условия в join-е не пробрасываются внутрь подзапроса;
Теперь пробрасываются. (За исключением некоторых случаев — например, в правую часть LEFT JOIN).
> распределённые join-ы выполняются неэффективно.
В некоторой мере осталось так же.
Sign up to leave a comment.
Сравнение аналитических in-memory баз данных