Согласен с вами, актуально! В какой-то мере ядрышко в тестах из статьи иногда даже помощнее, чем типичные ядра, что сегодня имеются в 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. Что же, выходит, скоро разработчикам предложат программировать прямо на тачскрине?
Корректный ответ состоит в том, что дисковые базы данных не плохие или хорошие сами по себе. Однако, они предназачены для работы с блоковым устройством хранения (block-storage device), коим является SSD и HDD. И это их классовое структурное ограничение. Имено поэтому, даже если вы дадите дисковой базе данных RAM-диск (тем самым потеряв вообще всякую персистентность), заметно быстрее она от этого работать не станет.
Вот скриншот по мотивам работы Стоунбрейкера «OLTP Through the Looking Glass» (слайд из лекции CMU, я думаю что не надо объяснять апологетам дисковых баз данных, кто такой Стоунбрейкер):
Слайд показывает, что дисковая база данных выполняет собственно полезную работу 12% времени, остальное время она, по сути, ворочает блоками.
Вот мои выдержки из лекции (дословно повторяю за автором лекций, Энди Павло, дабы не было повода думать, что это какие-то мои личные выдумки — Энди Павло явно более авторитетный источник чем я, достаточно посмотреть его биографию):
В формулировке из текущего обсуждения складывается ощущение, что эксперт — это такой педант, который даже не должен разговаривать с заказчиком, который не может сформулировать ему проблему. Потому он говорит, что решение невозможно, не желая признавать, что заказчик не владеет пространством решений. «Fuck you, that's why» эксперт. Конечно, если заказчик продолжает настаивать на своей формулировке, которая не даёт эксперту возможности указать решаемую проблему в пространстве решений, «на лад их дело не пойдёт» и контракт не состоится.
Дело в том, что видео про эксперта высмеивает именно эксперта, а не клиента. Одно из возможных решений:
Нет ничего хуже для программиста, чем узость и однобокость мышления.
У Ашана большой throughput (ск. всего неверно транскрибировали презентацию).