Category: общество

Гена

Звериный оскал в непосредственных ощущениях

https://www.facebook.com/144776752025/posts/10156715749852026/?app=fbl
По ссылке тупое видео "девочка просит кеннеди не допустить, чтобы русские сбросили ядерную бомбу на санта-клауса" (по крайней мере было).
После моего удивления "насколько же свирепая пропаганда, что даже дети боятся" Голос Америки молча убрал публикацию.
Гена

телеграммическое

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

Ну а Ололешей все пролюбят, но это уже частности.


Запись сделана с помощью m.livejournal.com.

Гена

лента как всегда

"Один из первых случаев отправки из России на учебу за границу за государственный счет зафиксирован еще в 1602 году. Царь Алексей Михайлович послал пятерых боярских детей в Англию. Россия и тогда нуждалась в умных и образованных людях. Но возвращаться никто из них не захотел."
https://m.lenta.ru/articles/2018/04/21/mozgi/
Почему-то за утечку переживает все больше такой народ, что их-то утечку можно только приветствовать.


Запись сделана с помощью m.livejournal.com.

Гена

Сирийская хрень или ишь чего отчебучивают (пикейножилетное)

Что интересно - Б.Обама в свое время с утра собирался вот-вот бомбить Сирию, а к вечеру уже передумывал.
Д.Трамп, что очень интересно, почему-то ведет себя ровно так же.
Кажется, проблема США не в том, что у них там какое-то глубинное государство, а в том, что их, судя по всему, несколько.
Гена

Хехе

https://kafka.apache.org/documentation/ (п. 5.4)
https://plumqqz.livejournal.com/62373.html

Только если от кафки народ прется, то на меня в свое время смотрели подозрительно.
Мой вариант, несколько, правда, модифицированный в сторону упрощения мне, разумеется, нравится больше.

Впрочем, и кафка, и мое творение подходят только для мусорных данных.
Зато быстро и просто, что есть то есть. Но для мусора.
Гена

Проблемы Постгреса (навскидку)

Сразу оговорюсь, что считаю Постгрес идеальным решением для малых и средних баз не с беспредельной нагрузкой.
Что это такое? Ну, например, "крупный банк федерального масштаба" держит там все заявки и работы ("купить новую инкассаторскую машину", "Марь Петровна жалуется, что ей нахамила операционистка" и т.п.)
На нем живет Авито - и им хватает.
На самом деле эта планка очень высокая, очень мало у кого есть требования, превышающие вышеуказанные.
Извините, но для 90% БД брать не Постгрес, а что-то пропиетарное - это либо идиотизм, либо коррупция.

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

1. Отсутствие внятного секционирования. Родное понимает только литералы, но не понимает параметры/колонки других таблиц. Иногда этого вполне достаточно (но тогда толку от него не так уж и много).
К чему ведет: проблемы с очень большими таблицами - очень большие таблицы для постгреса это плохо, а на маленькие нужным образом нарезать не получается.
Способы решения: pg_pathman (не без недостатков - секционирование только одноуровневое, нет глобальных индексов, нет отдельно секционированных индексов, сделать 500 тыс. секций очень скверная идея, но все сильно лучше того, что есть сейчас - а по факту сейчас ничего нет)
2. Компрессия - она есть только для колонок переменной длины, что не очень удобно, точнее, совсем неудобно; ситуация усугубляется еще и тем, что у постгреса высоки накладные расходы на строку, теоретически от 23 байт, фактически - с учетом выравнивая - 32 байта.
Есть компрессия ведущих колонок в индексе отдельным патчем, но из-за выравнивания от нее порой мало толка.
К чему ведет - большой объем данных, большой ввод-вывод, неэффективное расходование кеша.
В PostgresPro Enterprise есть компрессия, для варианта append-only таблиц вполне себе симпатичная. В ванильном нет и непонятно, когда будет, если вообще будет.
3. Вакуум - в настоящий момент только однопоточный (см. выше про таблицы), в версиях до 9.6 иногда остро вставала проблема wraparound'а (это выглядит как "база встала колом и третьи сутки что-то делает". Для бизнеса такое может быть кошмаром); но при желании этого можно добиться и на 9.6. В PostgresPro Enterprise она решена, может быть, попадет и в ваниллу.
4. Средства мониторинга и администрирования - вообще говоря, уже есть вчерне патч с wait events, разнесенный по statement'ам, но именно что вчерне. К сожалению, особого прогресса в этом не видно. С собственно инструментами все достаточно безрадостно - нет ни инструментов, ни толковой инфраструктуры.
5. Push executor/компиляция запросов в нативный код - есть наработки, но пока особого прогресса не видно и перспективы весьма туманны. Это сильно снижает производительность на больших выборках.
6. IOT - нет и не очень понятно, как их делать. Пока только разговоры.
8. Параллелизм на большом количестве ядер (эдак 256-384 и выше).
7. Куча всякого, иногда критически важного - инкреметальный бекап, чексуммы на clog, лимиты на запросы, триггеры на логин, трассировка выбранных сессий и т.д. и т.п.
8. Идиотская проблема, когда асинхронная реплика влияет на мастер.

Чтобы было понятно, на каких размерах у постгреса начинаются проблемы я постараюсь привести пару примеров:

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

Одна из компаний организовала стартап с генетически модфицированными муравьями для сопровождения грузов. Через каждые 50-500 метров муравьи выбегают из машины и бегут в ближайший спецмуравейник, где и выгружают данные об автомобиле (координаты, скорость, погодные условия) и грузе (состояние, комлектность (думаете, водители не воруют? О, как они воруют!), масса). Не знаю, чем кончилось, но были большим проблемы с постгресом - заливка данных/pgpool дурил и либо вообще останавливал обработку, либо давал неконситентный резльтат. Ну вы поняли про pgpool.

Компания (уж не знаю, по госзаказу или нет) отслеживала все доступные НЛО. Вы не представляете, сколько НЛО изучают нашу бедную планету и как они при этом мотаются по орбитам! Все было хорошо, пока не налетели на врапэраунд (ну да там только этим дело не ограничилось).

PS Для случая распухания таблиц и индексов в результате множества мелких транзакций (на что, судя по всему, напоролся Убер) решение тоже разрабатывается. Будет ли оно в ванилле, а если будет, то когда - это отдельный интересный вопрос.
Гена

Гипотеза (конспирология)

https://www.facebook.com/permalink.php?story_fbid=264653977352080&id=100014224390836

Как видно, перед входом в метро расчищен большой участок; такой же участок расчищен в Выхино, что еще интереснее - Выхино - станция на поверхности.
Следовательно, ожидаются большие скопления людей перед станциями; а раз так, ожидается, что будет время на то, чтобы спустить (и отвезти! см. Выхино) людей в метро.
По всей видимости развитие ситуации выглядит таким - сначала США наносят удар с баз ПРО/Томагавки, что-то сбивают, что-то долетает, после чего в дело уже идут серьезные предметы. В промежутке между первым и вторым осуществляется вывоз руководства, детей (см. реконструкцию чего ни попадя им. С.С.Собиянина/МЦК, т.е. часов 5-8) и оставшееся население отправляют в метро сколько влезет.
Как-то так.

Начало - http://plumqqz.livejournal.com/481350.html
Гена

Похвальное слово ОРМ.

Тут вот в комментариях проскочило
http://plumqqz.livejournal.com/495040.html?thread=5598912#t5598912
Собственно, я почти не согласен с этой публикацией.
Я гибернейта в последнее время наблюдал много всякого, и результат в среднем далеко не такой грустный; более того, обычно все более-менее работает и все более-менее довольны и гибернейт менять ни на что не собираются.

Это факт.

Факт и то, что гибернейт во всех случаях дал проблемы с производительностью различной степени серьезности и много тупой монотонной писанины. Факт, что без гибернейта написать имеющийся код было бы быстрее и он был бы в среднем более производительным; собственно говоря, применение гибернейта во всех случаях было совершенно бессмысленным. С другой стороны, я наблюдал проекты с серьезными проблемами как с логикой, так и с производительностью вовсе без всякого гибернейта; и что еще интереснее, проектов с проблемами в логике без гибернейта как бы даже не больше.
Если подумать, то получается удивительная вещь - применение неудобного, низкопроизводительного инструмента нередко оказывается более удачным, чем применение удобного и высокопроизводительного во всех смыслах - и во время написания, и во время выполнения. Лопатой иногда оказывается копать быстрее, чем экскаватором.
Почему?
А вот почему - из-за неудобности этого самого гибернейта. Раз нарисовав структуру и маппинги съехать на какую-то другую мучительно тяжело; и кривая, но стабильная структура БД оказывается удобней такой же кривой, но еще и нестабильной (была бы не кривая - была бы стабильная).

Что же делать?
А вот тут начинаются сложности - и в случае ОРМ, и в случае его отсутствия совершенно типичным ответом на вопрос "а зачем вы, собственно, используете distinct? какова вообще бизнес-цель этого метода" оказывается ответ "да... а давайте все-таки посмотрим, может быть, получится создать какой-то индекс?"
Т.е. люди не могут внятно сказать, что они делают. Становится понятно, почему кривое, но стабильное оказывается лучше кривого, но еще и нестабильного.

Я, собственно, к чему - определяющим фактором оказывается не технология, а степень обдуманности, проработанности задачи, и лучше кривые правила, чем нестабильные или противоречивые. Что такое заявка? Каким образом существует счет? Транзитивна ли дружба? В чем смысл жизни игрового персонажа?

Программирование вообще гуманитарное занятие.

PS Не надо думать, что владею тайной проникновения в суть задач. Это, увы, далеко не так.