Комментарии 13
НЛО прилетело и опубликовало эту надпись здесь
Это зависит от объёма данных, структуры таблиц и архитектуры самой базы.
Если у вас объем данных такой, что обработка его в классической СУБД займет 10 минут, то думаю в In-Memory вы просто не поместитесь. Или поместитесь не полностью.
Я не уверен, что понимаю термин in-memory. Болтология какая-то.
Но если речь идёт о последнем поколении бд, что держат в памяти данные, а на дисках только лог, то они бывают вполне себе распределенные.
См термин newsql
Само-собой. Тарантул какой-нибудь, например.
Вот только чтобы какой-нибудь аналитический Clickhouse обрабатывал запрос 10 минут, я даже не знаю сколько там должно быть данных. Да даже MySQL при наличии индексов запросы в много-гигабайтные таблицы обрабатывает меньше секунды.
Сколько у вас там данных? Десятки Тб? Это не получится держать In-Memory полностью за адекватные ресурсы.
По крайней мере я это так понимаю.
Вот только чтобы какой-нибудь аналитический 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 и вы покрыли все аналитические запроси.
Автор упорно путает тёплое с мягким, а солёное – с квадратным.
Oracle TimesTen – это реляционная БД или in-memory?
GridGain использует снимки или журналы?
Данные в Tarantool или Aerospike тоже доступны через SQL?
Можно чуть подробнее про кластеризацию веб-сессий? На картинке нарисована не «кластеризация», а «распределённое хранение».
В общем, что ни слово, то шедевр…
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 не имеют ограничений.
1. In-memory не «архитектура для веб-сервисов» а решение по кешированию либо в СУБД, либо между СУБД и веб-приложением.
2. Области применения In-Memory — почему такой список?
3. Предложенная архитектура — частное решение. Есть масса вариантов решений, от встроенных в СУБД до внешних.
4. Желательно сделать сравнительный анализ имеющихся СУБД с встроеным In-memory, чтоб понимать, а нужно ли усложнять архитектуру. Ведь если In-memory — опция СУБД, то автоматически решается проблема асинхронной синхронизации между данными в памяти и на диске.
5. Если делать с нуля, возьмите готовый SQL Server 2016+ в встроенным In-Memory, поддержкой авто-сохранения на диск и авто-загрузки с диска. Не нужно усложнять архитектуру и выдавать за шедевральное решение.
Кстати, знакомый чувак — контрактник в MS, специализируется на переводе OLTP продуктов на In-Memory. По его опыту: области применения In-Memory не имеют ограничений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
In-memory архитектура для веб-сервисов: основы технологии и принципы