Pull to refresh

Comments 13

UFO just landed and posted this here
Это зависит от объёма данных, структуры таблиц и архитектуры самой базы.
Если у вас объем данных такой, что обработка его в классической СУБД займет 10 минут, то думаю в In-Memory вы просто не поместитесь. Или поместитесь не полностью.

Я не уверен, что понимаю термин in-memory. Болтология какая-то.


Но если речь идёт о последнем поколении бд, что держат в памяти данные, а на дисках только лог, то они бывают вполне себе распределенные.


См термин newsql

Само-собой. Тарантул какой-нибудь, например.
Вот только чтобы какой-нибудь аналитический Clickhouse обрабатывал запрос 10 минут, я даже не знаю сколько там должно быть данных. Да даже MySQL при наличии индексов запросы в много-гигабайтные таблицы обрабатывает меньше секунды.

Сколько у вас там данных? Десятки Тб? Это не получится держать In-Memory полностью за адекватные ресурсы.

По крайней мере я это так понимаю.

Не понимаю, почему это не может быть в социальной сети на сотни миллионов пользователей сотни Тб данных :-)


Последний раз, когда я проверял, наши пользователи генерировали что-то вроде 2.5 Тб в сутки. А всего в первичном хранилище было порядка 2-3 Пб данных.

В In-Memory есть всякие интересные оптимизации, которые возможны, но не окупаются с дисками — например, «авто-выделение в справочник» повторяющихся значений или использование всяких трудносериализуемых структур данных в качестве индексов. Когда SAP внедряли свою HANA — у них получалось хранить данных в среднем (ЕМНИП) в 1.6 раза больше чем на машине установлено памяти. А с тех пор уже лет 10 прошло и много чего еще оптимизировали.

В классическую БД объёмы данных, характерные для сложных аналитических запросов, никто не кладёт.


А распределенные аналитические БД про "доли секунды" даже в рекламных проспектах не пишут, на то они и распределенные.

Не уменьшая значения и важности in memory баз можно писать и без маркетинговой фигни про и 5-10 минут. А по факту при правильной архитектуре и разделении на OLTP и DW аналитические отчёты за любой период — до 10с. И самая кровавая банковская классическая база неожиданно умеет и колоночное хранение и in memory и еще бог знает что еще. А прикрути сюда OLAP и вы покрыли все аналитические запроси.
Автор упорно путает тёплое с мягким, а солёное – с квадратным.

IMDB быстрее, чем реляционные БД

Oracle TimesTen – это реляционная БД или in-memory?

Для решения проблемы можно использовать снэпшоты — «снимок» базы данных, аналог бэкапа БД на жесткий диск, или записывать транзакции (логи), чтобы восстановить данные после перезагрузки.

GridGain использует снимки или журналы?

Данные, которые хранятся в In-Memory и доступны через SQL

Данные в Tarantool или Aerospike тоже доступны через SQL?

Он использует In-Memory, чтобы кластеризовать веб-сессии

Можно чуть подробнее про кластеризацию веб-сессий? На картинке нарисована не «кластеризация», а «распределённое хранение».

В общем, что ни слово, то шедевр…
Непрофессиональная статья.
1. In-memory не «архитектура для веб-сервисов» а решение по кешированию либо в СУБД, либо между СУБД и веб-приложением.
2. Области применения In-Memory — почему такой список?
3. Предложенная архитектура — частное решение. Есть масса вариантов решений, от встроенных в СУБД до внешних.
4. Желательно сделать сравнительный анализ имеющихся СУБД с встроеным In-memory, чтоб понимать, а нужно ли усложнять архитектуру. Ведь если In-memory — опция СУБД, то автоматически решается проблема асинхронной синхронизации между данными в памяти и на диске.
5. Если делать с нуля, возьмите готовый SQL Server 2016+ в встроенным In-Memory, поддержкой авто-сохранения на диск и авто-загрузки с диска. Не нужно усложнять архитектуру и выдавать за шедевральное решение.
Кстати, знакомый чувак — контрактник в MS, специализируется на переводе OLTP продуктов на In-Memory. По его опыту: области применения In-Memory не имеют ограничений.
Sign up to leave a comment.