Если упор делается на предметную область и связь с остальными слоями архитектуры автоматизирована, вплоть до генерации, то затраты на изменения можно существенно сократить. Об этом в статье.
Мысль понятна. Вся магия происходит в неком генераторе кода. Конструкторов NoCode/LowCode сейчас сотни на рынке. Но, на мой взгляд, основная проблема что каждый конструктор мечтает стать новой парадигмой программирования, но остается лишь набором шаблонов.
Аналогия со строительством устарела уже как минимум на 20 лет, когда Мартином Фаулером был обозначен термин "рефакторинг". Расскажите, пожалуйста, как происходит рефакторинг в строительстве? А в разработке ПО это ежедневная практика для большинстрва проектов.
В строительстве рефакторинг, это когда дядю Васю просят поменять трубы, например чугунные на пластиковые, которые проржавели и протекают.
Что касается СУБД. Дело в том, что вы в своём посте ставите БД на первое место, по сути объявляете её главенство. В современной разработке это уже не совсем так. В DDD, например, речь идёт о хранилище - некоторой прослойке, уменьшающей зависимость от конкретной СУБД и улучшающей возможности тестирования приложений. Ещё пример: брокер сообщений для микросервисов Apache Kafka, который, не являясь СУБД, может выполнять роль хранилища для некоторых задач.
Здесь нужно определится. Если вы за "соврменную разработку", тогда она мало имеет отношения к озвученным розовым пони вверху. Если разработка "не современная" то на БД вполне можно переложить функции DDD, схлопнув огромное количество ненужных слоев между UI и DB. Чтобы писать что-то декларативное с контрактами на вашем же скрине c инвариантами.
Смысл аналитика в том, чтобы ходить по стройке как дизайнер, мысленно визуализировать что должно примерно получится и ставить задачи прорабам и строителям. Совершенно не понятно причем тут длина итераций и как можно обойтись без аналитика. Эту роль кто-то должен выполнять, если проект в активной фазе строительства.
В этом случае можно было бы менять СУБД с минимальными изменениями в бизнес логике, а в идеале без изменений
В статье много фундаментальных правильных мыслей. Которые являются основой того, где все будет через лет 50. Но этот комментарий просто умножил все на ноль. СУБД это основа из основ. Ваш комментарий можно рассматривать как: Я хочу строить дома с взаимозаменяемым фундаментом, главное чтобы крыша и обои с плиткой в доме не потрескались. Что можно построить с таким архитектурным планом - неизвестно.
Это не большая вводная статья, попытка посмотреть на развитие поисковых систем с другой стороны. В следующих частях, будет «ближе к делу» и больше примеров. Суть — я пишу поисковый движок и оттачиваю ранжирующий алгоритм, будем сравнивать его работу с другими популярными поисковыми системами.
Judy Array достаточно большой документ, там используется до десятка разных способов сжатия узлов. Если интересует только этот метод сжатия, то это Patricia или Compact Trie описан в вики, напр. здесь en.wikipedia.org/wiki/Radix_tree
Если у вас всего один ключ veryveryverylongkey, то у вас самый простой примитив. Все что сделает Trie, просто запишет его в одну единственную область памяти как сплошной текст на максимальной скорости. Чуть сложнее будет если у вас будет еще один, похожий на этот ключ, тогда получится бранч на два ветвления Здесь есть обьяснение с картинками
Тут конечно можно было бы написать длинный пост, с большим количеством технических деталей, как и что работает. Но самом деле, я бы смотрел глубже, вообще в суть Trie. А суть в том, что он на самом деле намного ближе к уже работающим механизмам в мире биологии, он сам по себе моделирует эволюционный процесс, где каждый из узлов усложняется только по мере необходимости. Поэтому он часто находит применения в таких неожиданных областях, как например анализ цепочек ДНК. Но это отступление, если вернуться почему Trie работает быстрее, то все сведется к тому, что он лучше работает с линейной памятью. Он просто линейно пишет свои узлы, шаг за шагом. Пишет эффективно, если ключи похожи, он использует одни и теже сегменты два и более раз, не пишет ничего дважды, не перемещает уже записанные сегменты, ничего не балансирует, ничего глобально не перестраивает на ходу. Если у него есть конфликт, ставит шунт, говорит здесь ветвление делаем джамп и снова линейно пишет. Вообщем суммируя, сам по себе алгоритм, кроме всех прочих достоинств, более дружелюбен к блоку предсказания процессора, к кешам процессора и к линейной модели памяти вообще. Но конечно, чтобы раскрыть весь его потенциал, нужно многие вещи делать вручную. Если напр. на каждой операции создания вызывать создание узла через оператор new, то никаких конечно профитов по скорости не будет.
С семейством Binary Tree да. Это одна из причин, почему именно это семейство поисковых алгоритмов используется в базах данных. Хорошее предсказуемое поведение как по скорости работы так и по потреблению памяти в независимости от объемов данных, хотя тут тоже есть ньюансы. Пост выше касался хештаблиц и разных гибридных алгоритмов, которые используют вероятностную модель. С ними не все так однозначно.
Далеко не все алгоритмы. Хештаблицы построены на вероятностной модели. Такая модель подразумевает, что распределение по слотам идет достаточно равномерно без сильных перекосов. Но большие данные сами по себе подразумевают что может быть любой сценарий. В одних buckets будет всего несколько ключей, а в других 100500. И дальше все зависит предусмотрено ли это разработчиками. Плохое качество хешфункции и(или) большие данные могут «подвесить» или «развалить» практически любую хештаблицу.
Спасибо за отзыв. Действительно, сейчас когда говорят о Trie, зачастую подразумевают тот-же Suffix-Tree, хотя это всего лишь один из подвидов применения Trie, где добавив все возможные суффиксы строк получаются доступными такие операции как — поиск подстроки, количество различных подстрок в строке и др. Как это работает достаточно хорошо описано в разных источниках, есть посты и на этом сайте. Однако область применения Trie, как и любого Key/Value контейнера, не ограничивается работой с текстом или алгоритмами архивирования. Если реализация не тривиальная, то работать такой контейнер может на уровне или быстрее хештаблиц при этом потребляя меньше памяти и предоставляя более широкую функциональность. В таком ключе статей мало, почему я и решил написать пост выше на хабре. Подробного описания алгоритмов для HArray пока что нет, но есть подобное описание для JudyArray. Как по мне, то эти документы как их не пиши, будут тяжелыми для восприятия, поэтому я больше склоняюсь к мысли просто записать несколько видео-лекций возле доски в будущем.
Можно конечно, наверняка от этого была бы польза. Но самые сложные баги что я здесь ловил, были алгоритмические. Обычно дело обстояло так, на вставке 345123 ключа, что-то идет не так, но баг никак себя не проявляет и структура умудряется безошибочно вставить еще несколько сотен тысяч ключей после чего необьяснимо крашится в каком нибудь проприетарном коде. Такие баги пришлось ловить, написав отдельную функциональность которая тщательно проверяет Healthy всей памяти после вставки каждого ключа, чтобы засечь баг как можно раньше. Для структуры, которая кодирует данные чуть менее чем полностью через GoTo по другому не получается. На сейчас, в основных кейсах, структура достаточно стабильно работает под Linux и Windows, на х64/x32 платформах. В одном из тестов удалось вставить даже около 1 млрд ключей и ничего не рассыпалось.
Мысль понятна. Вся магия происходит в неком генераторе кода. Конструкторов NoCode/LowCode сейчас сотни на рынке. Но, на мой взгляд, основная проблема что каждый конструктор мечтает стать новой парадигмой программирования, но остается лишь набором шаблонов.
В строительстве рефакторинг, это когда дядю Васю просят поменять трубы, например чугунные на пластиковые, которые проржавели и протекают.
Здесь нужно определится. Если вы за "соврменную разработку", тогда она мало имеет отношения к озвученным розовым пони вверху. Если разработка "не современная" то на БД вполне можно переложить функции DDD, схлопнув огромное количество ненужных слоев между UI и DB. Чтобы писать что-то декларативное с контрактами на вашем же скрине c инвариантами.
Смысл аналитика в том, чтобы ходить по стройке как дизайнер, мысленно визуализировать что должно примерно получится и ставить задачи прорабам и строителям. Совершенно не понятно причем тут длина итераций и как можно обойтись без аналитика. Эту роль кто-то должен выполнять, если проект в активной фазе строительства.
В статье много фундаментальных правильных мыслей. Которые являются основой того, где все будет через лет 50. Но этот комментарий просто умножил все на ноль. СУБД это основа из основ. Ваш комментарий можно рассматривать как: Я хочу строить дома с взаимозаменяемым фундаментом, главное чтобы крыша и обои с плиткой в доме не потрескались. Что можно построить с таким архитектурным планом - неизвестно.
В остальном, должно быть не скучно
s1.radikale.ru/uploads/2014/8/21/e3bcf5ec37d945430cf00a44caed78b1-full.jpg
Да, опечатка, обязательно исправлю. Спасибо за внимательность, порой самые очевидные ошибки сложнее всего заметить.