Есть тонкости. Отключаем логи — это уже, считай, memcached. В redis, к примеру, лог асинхронный — пишется на диск каждую секунду. В общем, это уже не полноценные замены DiskDB. В Oracle 12c, как я понимаю, встроено in-memory option — не является IMDB как таковой, но является прозрачным колоночно-организованным кешем, который поддерживается в памяти параллельно с основным построчным дисковым хранилищем. Их же TimesTen является полноценной IMDB и, вообще говоря, другой продукт. Есть ещё гибридные решения типа SAP HANA — там row и column одновременно без копий данных, интересное устройство само по себе, которого пока нет у других производителей.
Спасибо за наводку с вопросами, — видимо, я не смогу избежать подготовки статьи по мотивам CMU лекции. Соль в том, как DDB оперирует блоками (как работает буферный пул) и к чему это приводит в сравнении с IMDB. Это нетривиальное объяснение, оно не вписывается в один абзац, нужны картинки.
Тянет на статью :) Но как только это станет понятно (и все DDB так устроены) — странет понятно, о чём весь сыр-бор. Это общий принцип, которому следуют все DDB. И он, конечно, вовсе в корне не о том, что диск ворочает головкой. Это физическая особенность железа. SSD не ворочает головкой, но ситуация там тоже не сахар для DDB. Недавно на хабре была статья, где SQL Server разгоняли суперсовременным NAND сервером в TPC-тестах, добились прироста… +35%. Ну это, как бы, даже не разы. То есть, вовсе не в железе дело, а в принципе работы баз.
На самом деле, легко подобрать нагрузку, где в IMDB диск станет узким горлышком. Проблема в том, что у DDB эта граница — тысячи транзакций, у IMDB — миллионы.
Согласен с вами, актуально! В какой-то мере ядрышко в тестах из статьи иногда даже помощнее, чем типичные ядра, что сегодня имеются в commodity машинах. У рабочей лошадки Skylake i7-6700k даже L2 cache такой же, как у Pentium 4. Или вы предлагаете тезис, что современные процессоры значительно лучше в сравнении с Pentium 4 для дисковых баз данных? Понятно, что многоядерность опять же сильно более полезна для in-memory баз данных, нежели для дисковых. А что такого уникального именно для дисковых?
Эти минусы, кстати, будут нивелированы новым железом. Например, NVM 3d-xpoint от Интел (в DIMM-формфакторе уже в 2017-м году) — это плашки постоянной (неволатильной) памяти объёмом 3 Тб штука, со скоростью чтения порядка DRAM, записи — раз в 5-10 медленнее DRAM. Эта память также является byte-addressable, как и DRAM. То есть, базы данных, ориентированные на block-storage, становятся как бы всё менее актуальными. Через пять лет такое железо будет в рамках нормы уже, и дисковые базы данных совсем отойдут. В стратегии Интел — принести вычисления ближе к данным, минимизируя число слоёв: вместо двух слоёв — постоянного диска и непостоянной памяти — будет просто постоянная память, и её будет много. Блоковые устройства становятся уделом чисто архивных данных.
Не можно, нужно: http://nms.csail.mit.edu/~stavros/pubs/OLTP_sigmod08.pdf (ссылка из верхнего — не моего — комментария). Кстати, настаиваю не я, а автор всего этого мувмента — Стоунбрейкер (который, например, автор того, что сейчас является PostgreSQL; просто товарищ очень активный и не стоит на месте, просто наслажлаясь уже имеющимися результатами своего труда).
Часто сталкиваюсь с утверждениями, что «Ведь дисковая база данных вся влазит в in-memory кэш, зачем тогда нужны in-memory базы данных вообще; это хайп и маркетинг, всё давно изобретено в тёплых ламповых RDBMS». Для того чтобы парировать это некорректное утверждение, лекция №2 из курса CMU (первая ссылка), на мой взгляд, дает на сегодня самый полноценный и аргументированный ответ.
Корректный ответ состоит в том, что дисковые базы данных не плохие или хорошие сами по себе. Однако, они предназачены для работы с блоковым устройством хранения (block-storage device), коим является SSD и HDD. И это их классовое структурное ограничение. Имено поэтому, даже если вы дадите дисковой базе данных RAM-диск (тем самым потеряв вообще всякую персистентность), заметно быстрее она от этого работать не станет.
Вот скриншот по мотивам работы Стоунбрейкера «OLTP Through the Looking Glass» (слайд из лекции CMU, я думаю что не надо объяснять апологетам дисковых баз данных, кто такой Стоунбрейкер):
Слайд показывает, что дисковая база данных выполняет собственно полезную работу 12% времени, остальное время она, по сути, ворочает блоками.
Вот мои выдержки из лекции (дословно повторяю за автором лекций, Энди Павло, дабы не было повода думать, что это какие-то мои личные выдумки — Энди Павло явно более авторитетный источник чем я, достаточно посмотреть его биографию):
Why not use traditional disk-oriented DB with large enough cache? IMDB are completely designed from the ground-up for in-memory execution. Disk-based: block-oriented device, 4K blocks. Fetches blocks. Buffer pool manager as a cache. Manage movement of data back and forth between block-storage device and buffer pool. IMDB doesn’t have a buffer pool. Buffer pool manager is the differentiator. If you run 100 Gb RAM for a DB of 10 Gb, MySQL will never know that we will never run out of RAM – it is built in such a way that it will always do locking, latching, swizzling, buffer load etc. Then, in transaction management: disk-oriented system assumes any time trxn accesses the tuple, it might not be in memory and going to be able to stall, getting space for a new tuple. Interleaving stalls leads to locks and latches, locks are kept in a separate data structure (to avoid page faults). Actually modifying the tuples, traversing indices, executing queries – “OLTP through a looking glass”. Buffer pool 30%, lock manager 30%, recovery manager 28%. 12% is for actual useful work.
Нет. Заказчик имеет некоторую конкретную проблему, которая решаема в некотором пространстве решений, которое ему априори неизвестно. Он готов платить за решение. Поскольку это пространство ему неизвестно, он формулирует задачу некорректно, косноязычно и т.д. Эксперт знает пространство решений, но не знает проблемы заказчика. Задача эксперта, в первую очередь — осознать проблему. Это задача переговоров, коммуникации и перевода. Но эксперту такая трансляция должна быть по зубам — ведь он знает всё пространство, и поэтому обозревает целое семейство возможных проблем.
В формулировке из текущего обсуждения складывается ощущение, что эксперт — это такой педант, который даже не должен разговаривать с заказчиком, который не может сформулировать ему проблему. Потому он говорит, что решение невозможно, не желая признавать, что заказчик не владеет пространством решений. «Fuck you, that's why» эксперт. Конечно, если заказчик продолжает настаивать на своей формулировке, которая не даёт эксперту возможности указать решаемую проблему в пространстве решений, «на лад их дело не пойдёт» и контракт не состоится.
Вообще, представление клиентов о работе отлично отражает старое, но не теряющее актуальности видео про 7 красных перпендикулярных линий, некоторые из которых должны быть нарисованы зелеными чернилами, а некоторые — прозрачными.
Дело в том, что видео про эксперта высмеивает именно эксперта, а не клиента. Одно из возможных решений:
Нет ничего хуже для программиста, чем узость и однобокость мышления.
Наверное убивают git.exe, это быстро — память структур удаляется скопом и не требует явной итерации для удаления. При работе с либой надо явно зачищать память, а это долго.
У меня у одного такое ощущение, что Apache Spark неоправданно захайпована? Вот сейчас начал читать и подумал: «ну сейчас наконец-то технически грамотно объяснят самую суть, мякотку этой технологии — что же на самом деле в ней стоящего и нового». Но с первых же строк очередной «MongoDB is web scale». Интернеты растут, IoT наступает, Big Data, неограниченное (буквально экспоненциальное) масштабирование! Если без хайпа, рекомендую вот это http://www.redbook.io/ от Стоунбрейкера: пройись по страничкам по ключевому слову Spark.
Вот например: https://www.youtube.com/results?search_query=dell+xps+15+problems. Устройство за 2 000 USD изготовлено некачественно, и сервис осуществляется некачественно. Я хотел приобрести Dell XPS 15, но волосы дыбом. «Бизьнез». В итоге приобретается Thinkpad T460p.
Эх, это и печалит. Отнюдь не все проекты так просты (считаю, что мнение об очевидности зависимостей во всех проектах разработки ПО, продвигаемых некоторыми, ошибочно и является явным популизмом). Например, разработка движка базы данных — не писать же свой инструмент планирования работ. А зависимостей — тьма! В этом плане, например, прекрасен MS Project. Закинул примерные оценки по крупным частям работы, завязал зависимости, прописал исполнителей — опа, leveling — и вот у тебя в руках уже резонные оценки по времени на milestone-ах и учитывающий зависимости порядок работ для каждого человека. Никакой магии и лишней работы для менеджера проектов. Но, к сожалению, прекрасные стороны MS Project на этом кончаются — понятно, что составление расписаний можно и самому запрограммировать. Но это так брутально, делать это самому — на дворе 2016 год!
Какие инструменты были рекомендованы? Доска и фломастеры со стикерами явно не лучшее средство для актуализации и визуализации зависимостей — спирта в маркерах не напасёшься :)
Эх и самоуверенность. OSX превратилась из желанной платформы в наиболее ретроградную ОС современности. Железо в макбуках pro не обновлялось принципиально с 2013 года. Под прайс-тегом элитного устройства продаётся старьё. Дизайн корпуса — всё та же мыльница, как если бы внезапно автопроизводители вновь стали выпускать авто в духе биодизайна. Вместо исправления дизайна корпуса, в грядущем обновлении Apple добавляет в прошки — вы только вдумайтесь — жк-панель вместо ряда функциональных клавиш. То есть делают как раз то, за что Lenovo в 2012 закидали помидорами и они срочно стали возвращать всё на место. Apple как бы всем своим видом говорит: разработчики, нам с вами не по пути, велкам домохозяйки! Вместо срочного исправления ошибок и выпуска обновлённых, современных линеек устройств, привлекательных для технократов, Apple выдаёт перл, что iPad Pro — это отличный компьютер общего назначения: https://www.youtube.com/watch?v=1zPYW6Ipgok. Что же, выходит, скоро разработчикам предложат программировать прямо на тачскрине?
Тянет на статью :) Но как только это станет понятно (и все DDB так устроены) — странет понятно, о чём весь сыр-бор. Это общий принцип, которому следуют все DDB. И он, конечно, вовсе в корне не о том, что диск ворочает головкой. Это физическая особенность железа. SSD не ворочает головкой, но ситуация там тоже не сахар для DDB. Недавно на хабре была статья, где SQL Server разгоняли суперсовременным NAND сервером в TPC-тестах, добились прироста… +35%. Ну это, как бы, даже не разы. То есть, вовсе не в железе дело, а в принципе работы баз.
На самом деле, легко подобрать нагрузку, где в IMDB диск станет узким горлышком. Проблема в том, что у DDB эта граница — тысячи транзакций, у IMDB — миллионы.
Корректный ответ состоит в том, что дисковые базы данных не плохие или хорошие сами по себе. Однако, они предназачены для работы с блоковым устройством хранения (block-storage device), коим является SSD и HDD. И это их классовое структурное ограничение. Имено поэтому, даже если вы дадите дисковой базе данных RAM-диск (тем самым потеряв вообще всякую персистентность), заметно быстрее она от этого работать не станет.
Вот скриншот по мотивам работы Стоунбрейкера «OLTP Through the Looking Glass» (слайд из лекции CMU, я думаю что не надо объяснять апологетам дисковых баз данных, кто такой Стоунбрейкер):
Слайд показывает, что дисковая база данных выполняет собственно полезную работу 12% времени, остальное время она, по сути, ворочает блоками.
Вот мои выдержки из лекции (дословно повторяю за автором лекций, Энди Павло, дабы не было повода думать, что это какие-то мои личные выдумки — Энди Павло явно более авторитетный источник чем я, достаточно посмотреть его биографию):
В формулировке из текущего обсуждения складывается ощущение, что эксперт — это такой педант, который даже не должен разговаривать с заказчиком, который не может сформулировать ему проблему. Потому он говорит, что решение невозможно, не желая признавать, что заказчик не владеет пространством решений. «Fuck you, that's why» эксперт. Конечно, если заказчик продолжает настаивать на своей формулировке, которая не даёт эксперту возможности указать решаемую проблему в пространстве решений, «на лад их дело не пойдёт» и контракт не состоится.
Дело в том, что видео про эксперта высмеивает именно эксперта, а не клиента. Одно из возможных решений:
Нет ничего хуже для программиста, чем узость и однобокость мышления.
У Ашана большой throughput (ск. всего неверно транскрибировали презентацию).