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

"Мойдодыр"

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

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

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

Ад холокоста

ссылко

Столичный школьник получил радиационное облучение в результате опасного домашнего эксперимента. Как рассказали «Росбалту» в пресс-службе московского управления Роспотребнадзора, мальчик купил на рынке нужные детали и сам собрал рентгеновский аппарат.

Помнится в детстве я развлекался с высоковольтными генераторами. Счас блин, таких деталей хрен найдешь (типа 18 конденсаторов на 10 кв и 1.6 нФ),а тогда в перестроечное время - пошел, купил в "Электронике" на логойском тракте, причем за какие-то копейки. Или там пару ферритовых колец 20 см в диаметре. Или транзистор непонятно от чего, но судя по всему, выдерживающий какие-то сотни ампер и сотни вольт, на сторожевском радиорынке.

PS: Кстати, генератор у меня до сих пор работает, и где-то на работе, помнится мне, валялась рентгеновская трубка, муахахахаха. Жаль она метров на сто пучком когерентным не светит, а то можно было бы алкашам во дворе устраивать радиационную стерилизацию нахрен.