Category: it

Гена

Торжество блокчейна

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

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

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

Clickhouse

https://clickhouse.yandex/reference_ru.html

Почитал; сложилось впечатление, что это какой-то сервер грепа двоичных логов.
Сам собой встал вопрос - а что, разве никто никакую библиотеку для чего-то подобного не видел? Ну не может же не быть.
Гена

Двунаправленная репликация как высокотехнологическое шарлатанство

Двунаправленная репликация или репликация мастер-мастер, как представляется, по крайней мере по мнению ее сторонников, призвана решить две проблемы -

* Масштабирование
* Обеспечение распределенных вычислений.


Collapse )
Гена

"Вы думаете, я за вас свою работу делать буду?"

https://www.facebook.com/tatyana.grigorenko.399/posts/956890594388335?fref=nf&pnref=story
Дама рассуждает вполне типично - если некто делает то, что ей, даме, непонятно, то он тупой. Если таких много - стало быть, они все тупые, инертные недоумки и тупость распространена чрезвычайно широко. Очень удобная и приятная позиция; я б ничего против такой позиции не имел, да вот только жаль, что эта дама, кажется, ставит перед людьми задачи.

По сути вопроса - практически никогда инициатива не совпадает с тем, что грезится заказчику (у меня ни разу не совпадала); а раз так, то инициативно написанный код надо либо выкидывать, что, в общем-то, неплохо, либо править, что хуже - код до бесконечности править нельзя, и чем больше его правят, тем он хуже. Когда код правке уже практически не поддается, изобретаются различные ухищрения, что ситуацию совсем не улучшает; и так можно продолжать почти бесконечно, только что-то не видел я таких людей, кому бы это нравилось.
Собственно, что получается - с точки зрения дамы программист не хочет думать и инициативничать, а с точки зрения программиста он не хочет пихать в код неизвестно что, которое потом еще и переделывать придется; и вот кто тут не думает - большой вопрос.
Вообще есть волшебное средство - простота и ясность, но им обычно не пользуются - потому что думать лень, мол, делайте то, что я имею или буду иметь в виду, инициативу проявляйте, в общем, давайте, работайте, не сидите сиднем.
Мне вот прям интересно - если б ей дом строили и раствора не было - она бы так и говорила строителям - мол, ну придумайте че-нить?

Что же, товарищи, у меня для нас плохие новости - других аналитиков, кажется, нет в природе.
Гена

О философско-филологическом аспекте программизма.

Я довольно давно встречаю утверждения, что программистов надо готовить в ПТУ, потому что там все просто и ваще, а вот в вузах надо готовить не программистов, а Инженеров, которые будут мыслью пронзать чё надо и все делать классно.
Collapse )
Гена

Это, кажется, судьба

http://roem.ru/2014/05/15/yndxxslt99349/

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

Их нужно поддерживать, постепенно переводя на новые технологии (Node.js)...


Вот ведь в полный рост Collapse ).
Гена

СУБД-2. Блокировки и бекап. Теорема о сериализации

Блокировки вообще.
С блокировками в СУБД при взгляде с птичьего полета все очень просто (мы говорим для простоты только о блокировках строк) - они бывают либо shared, либо exclusive, как и везде, но вот ведут себя они не то, чтобы неожиданно, но своеобразно: во всякой СУБД (кроме таких экзотических, по крайней мере для меня, про которые я даже и не слышал) всякая транзакция все блокировки, возникающие в результате изменения данных (они, понятное дело, все exclusive), освобождает только и исключительно при выполнении commit или rollback. Это называется двухфазной блокировкой (2PL, https://en.wikipedia.org/wiki/Two-phase_locking - ни в коем случае не надо путать с двухфазным коммитом (2PC), это совсем другая история, о которой как-нибудь в следующий раз).
(Мне тут сообщают, что для знающего вопрос изложено примитивно, а для незнающего - непонятно. Ну... да. Так что приношу свои извинения).
Collapse )
Гена

Все ясно. Оказывается, я псих. И друзья мои - тоже психи. Ну, большинство, по крайней мере

Гена

Поучительное

XML файл должен соответствовать следующей структуре:
заголовок (допускается использование кодировок UTF-8 и windows-1251)
- блок "data"
- блок "devices"
- блоки "device" с полями:
  - "product_id"
  - "group_id"
  - "model_id"
  - "power"
  - "power_key"
...


Чему нас учит этот удивительный кусок? Немногому, но важному - если внедрять всякие xsd, то кто-то пользоваться ими будет, а кто-то предпочтет описывать структуру жестами.
Следовательно, надо не долбать мозг себе и окружающим и сразу придумывать хорошо описываемый жестами и плясками формат данных. Можно, конечно, сказать, что это унизительно - ориентироваться на самых тормозных представителей. Ну не без этого, разумеется, но - но! - если с документацией на стандарт могут легко разобраться самые тупые, то не самым тупым с ней проблем совсем не будет.
К сожалению, секрет разработки таких стандартов до сих пор еще не найден.