Category: история

Category was added automatically. Read all entries about "история".

LSM tree и иммутабельные данные

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

А существует ли схожий алгоритм для случая, когда старые версии должны быть доступны для приложения? Например, если мы хотим хранить всю предысторию изменений состояния системы, для аудита и/или репликации, мемоизации каких-нибудь хранимых аггрегатов с пересчетом по мере необходимости и прочего такого.
Причем, если по-хорошему, это дело должно еще поддерживать partitioning, инкрементальные бэкапы, и прочее такое БД-админство, чтобы когда это дело будет хранить историю жизни за 10-15 лет, обслуживание его не выродилось в кошмар.

Вообще, откуда возникла такая идея: если реализовывать "историю"(== аудит, репликацию, пересчеты мемоизированных агрегатов) триггерами в SQL базе (если СУБД сама не умеет логи изменений), если по сути бизнес-логики нужна история изменений/версионность данных (редактирование проводок, исторические атрибуты контрагентов, изменение структуры предприятия) и не дай бог, туда надо маппить какие-нибудь графы, это дело вырождается в какую-то откровенную чернь, которая на SQL выглядит очень грустно.

В принципе, используя описанное в этой книжке: http://www.assertedversioning.com/ http://www.amazon.com/Managing-Time-Relational-Databases-Temporal/dp/0123750415 и http://www.postgresql.org/docs/9.2/static/rangetypes.html можно было бы сделать более-менее эффективное решение, но SQL не очень хорошо умеет в реюз кода (т.е. вынести весь код управления версионностью в один модуль для всех таблиц, скорее всего, не выйдет). И вопросы с репликацией, а особенно историей редактирования каких-нибудь графов остаются - неудобно оно все.

Неумение жить в нормальных условиях

http://kirguduev.livejournal.com/549391.html?thread=9889039#t9889039

"Граждане" "России" заебались жить мирно и пророчествуют о скорой войне.
Надеюсь, хоть на этот раз дикари сцепятся с такими же дикарями-азиатами и не полезут в Европу по нашей территории.
Откровенно подзадрал этот вечный исторический пиздец - то войны, то революции, то еще какая-нибудь поебень.

Опердень и undo

А вот скажите мне, как истинные оперденьщики, модно ли сейчас делать в оперденях функцию "откатить изменения в паре сотен документов на неделю назад, потому что пользователи сошли с ума и сделали что-то не то"?

Возникает такая потребность нечасто, поэтому я обхожусь старой копией БД и экспортом-импортом из нее в текущую БД, но может быть, это рукожопие за которое положено быть запсенным кахесом и давно все делают иммутабельные БД со всеми версиями происходящего и дичайшими алгоритмами отката части графа документов на предыдущую версию?

Про импеданс с положительной мнимой частью.

Ненавидите ли вы трансформаторы и индуктивности так, как ненавижу их я?
У меня еще с радиолюбительского детства существует неприязнь ко всему, в чем существует ненулевое значение мнимой составляющей импеданса.

Из-за того, что в СССР не было китайских сельпо, делать все приходилось из подручного говна и палок, а измерить индуктивность и прочие характеристики было нечем, и формулы для расчета были эмпирические и взятые из "Справочника сельского электрика". Каркасы от индуктивностей из радиоприемника "Океан" плавились при их выпаивании. И при этом не существовало обычного ряда значений, как для конденсаторов или резисторов. Мелкие тороидальные индуктивности приходилось наматывать с помощью челнока, на тонкой проволоке возникали затяжки, это все рвалось, выводы отламывались, приходилось делать заново, итд итп.

Гигантская Писька-Змея, король писек, или аксессуары для софта на питоне

Как известно, у меня есть одна собственная прога на питоне и сейчас я, несмотря на объективные возражения ребе айседа, долблюсь с софтом, написанным на нем же (аналогов нет, на кложури я за разумное время это не перепишу, хотя собираюсь).
Чтобы духи рукожопия были благосклонны ко мне, пришлось совершить ритуальную покупку во имя Гвидо ван Россума:

Ruby и Python

https://plus.google.com/111869347391871267742/posts/2MASjnS1APG

"У рубистов маленькая писька, ну, или они думают, что используя руби у них маленькая писька становится (следуя стереотипу о азиатских/японских пенисах)
А вот питон, который обычно вызывает их ярость, наоборот собой символизирует символ огромной письки-змеи, короля писек, что вызывает их подсознательную ярость :)(это все шутка, если чо)"

Огромный Писько-Змей, Король Писек. Концепт ок.

На что ориентироваться при разработке программ

Юзер может вводить что угодно. Хоть стихи про гитлера на иврите в поле для целого числа.

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

Опять RDBMS срач

zamotivator опять поднял свою любимую тему.

Я таки сформулировал, чего меня не устраивает в РСУБД, перепощу сюда чтобы не забыть:

Что меня бесит в СУБД:

1) Хреновая интеграция баз и статически типизированных языков. Т.е. постоянно нужно делать что-то вроде FieldByName("имя_поля") и тому подобное, что очень легко сломать. Обходится кодогенерацией из схемы базы или из запросов и проверкой при запуске что схему не изменили несовместимым образом. ORM и тому подобное - это так, паллиатив, вынесли литералы из кода в конфиги.

2) Хреновое взаимодействие с контролем версий. Я бы сказал, очень хреновое, т.к. в общем случае изменения в базе необратимы, в отличие от кода в VCS. Как решить - а хер его знает, т.к. в отличие от кода, который можно откатить на старую версию по частям и в худшем случае он просто не соберется, в базе все взаимосвязано так, что хрен ты откатишь одно изменение, если поверх него уже сделаны другие. Я даже теоретически себе это с трудом представляю. Короче "самосогласованный откат изменений в графе", можно вешаться.

3) Это тоже относится к 2) про это еще rainman_rocks писал - программисты ненавидят ALTER TABLE, т.к. изменить и перекомпилировать код гораздо проще чем изменить базу.

4) Хреновейшая работа с вложенными коллекциями и вообще всем, что сложнее чем "список плоских записей". Проблема 1+N запросов и тому подобное. Лечится исключительно методом "встраиваем прямо внутрь БД сборку сложных объектов из результатов запросов и сериализацию полученного в какой-нибудь JSON", поимев в результате логику в БД, зависимости от таблиц и прочий шлак. Еще можно рядом с СУБД поставить сервер приложений, делающий то же самое, но внутри сервера быстрее. А еще в дотнете в норме 1+N запрос еще и не выполнишь - не у всех драйверов доступа можно лениво фетчить одновременно из двух резальтсетов.


1 и 4 можно исправить, впилив в сервер какой-нибудь язык с явной поддержкой нормальных типов(кто сказал Haskell?), а в клиентскую либу вставив автоматическую кодогенерацию (на всех over 9000 языках) из запросов и проверку схемы при подключении.

2 и 3 - хрен его знает, наверно теорию применения изменений в графах неебического размера придумывать надо, и использовать БД, которая не удаляет данные даже если их дропнули, изменили, итд. Тогда откатится будет в некоторых случаях возможно. Что делать с стогигабайтными БД в таком случае - наверно вешаться.
И в системы контроля версий встраивать модули интеграции с БД, которые бы генерировали скрипты применения и отмены изменений. Или при разработке с использованием БД использовать систему контроля версий прямо в этой же БД, с явной процедурой деплоймента, т.е. созданием из текущей ревизии собранного кода+все миграции со всех других вариантов БД из прошлых ревизий.

Недвижимость Канады

Сабж является непременной темой, когда мы в чатике общаемся со знакомыми канадскими иммигрантами. Конкретно, непременная тема срача - это то, что в канаде бетонные и кирпичные дома запрещены, строить себе дом тоже запрещено, а максимум того, что может позволить себе купить хороший сисадмин-линуксоид в кредит - это 2к квартира в доме 1910 года постройки из сгнившей фанеры и кирпича.

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

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

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

"Мойдодыр"

Смотрю сабжевый мультик, вроде бы 1954 года. Это просто ад холокоста, как, практически, и все мультики по Чуковскому.

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

Короче, жена обещала мне в голову чем-кинуть, если я буду ребенку интерпретировать мультики в таком ключе.