а если взять patricia trie, например с того же гитхаба github.com/tchap/go-patricia, то можно получить еще более удивительные результаты по потреблению памяти на разреженных данных

всегда есть Builder для этого

когда-то давно было. теперь не втаскиваем вообще (если не считать баги с продакшена, но они идут отдельным процессом и на общее капасити не влияют).
двухнедельные итерации, еженедельный релизный цикл, дважды в неделю хотфиксы

мы внедрили 4х дневную неделю при условии успешного завершения спринта. При этом есть ограничение — капасити на следующий спринт рассчитывается из таких же 5-дневных недель.
С одной стороны это позволяет не снижать общий результат. С другой — повышается эффективность в эти дни. А как результат — планирование и предсказуемость спринтов сильно улучшились.

Использовали в тестовом режиме на одной команде примерно полгода, сейчас включили всес остальные в те же условия, так что есть возможность сравнить до\после\во время\вместо и т.д. :)

ага. перевод…

в статье про разные алгоритмы речь идет про пересечение прямоугольников. В случае же с точками вам бы:
а) больше подошло r-tree
б) было бы достаточно вообще детектора коллизий на основе очереди с приоритетами и расчетом новой коллизии при наступлении каждого из событий

нинада :'(

кажется оптимальное решение можно построить на графах с очередью с приоритетами и обрезкой ветвей. Это будет много изящнее чем брутфорс :) Выглядит похожей на классические пятнашки с точки зрения алгоритма

ну вот же — вы все правильно расписали :) менеджится в две-три стадии в зависимости от комплексности изменения. автоматизированных средств я пока не встречал да и сложно себе их представляю.

Кстати, если нет желания переходить на GQL, но есть желание получить псевдо бесплатно в существующем REST такой же возможности расширения обьектов, то на помощь приходит библиотека-прослойка поверх API

liquibase решает. А с недавних версий MySQL, например, поддерживает online ddl. А мейнтененс СУБД — это вопрос вашей архитектуры. Для Mongo — это, например, mongos. А для того же MySQL — mysql proxy… Масса вариантов. Исходить надо из задачи

добавьте предфильтр перед Левенштейном. Например н-граммный. Памяти будет есть чуть больше, но словарь можно будет существенно сократить для постобработки и деградация будет не экспоненциальной.
ну а на самом верху я бы вообще держал фильтр блюма, который позволил бы точные совпадения отдавать вообще с минимумом задействования ресурсов

занимался немного вопросом: youtu.be/G2zxxmF2iiA :)

из статьи это не очевидно (точнее очевино как раз обратное)

Вот еще интересные наблюдения, как LIMIT 1 наоборот убивает производительность: http://datamangling.com/2014/01/17/limit-1-and-performance-in-a-postgres-query/

Очень странно, что Постгрес не использует оптимизацию по отсечению результатов с limit при сканировании, что выглядит логично.
MySQL, к примеру, использует: http://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html

ага, у меня в телефоне тоже irda есть, и тоже софт для «управления всем», вот только это самое «все», видимо, не очень в курсе и управляться в большинстве своем отказывается, ибо везде поприетарщина и нужно иметь огромную актуальную базу протоколов.
в общем идея ок, но универсальны эти устройства весьма условно

вместо реле можно взять тиристор + moc для него

раз уж Вы начали размечать страницы, то почему бы просто не брать xpath выбранных элементов и не приводить их к ближайшему общему предку, которого и извлекать?
Ну и статья, на которую Вы ссылаетесь в начале, о том как находить нужный контент на странице БЕЗ учителя и в этом ее смысл.

четвертый год работает iRobot 5xx. Работает каждый день, дважды (два ребенка, две кошки, ковролин)
из обслуживания: трижды менял блок щеток. Но: если бы поменял сразу на блок от 7хх, то не менял бы ни разу