Привет. В прошлом году я начал снимать серию программ/интервью на тему цифровой трансформации бизнеса ( они здесь, кому интересно - подписывайтесь ).
Эти программы были на стыке IT и бизнеса, но все же больше о бизнесе.
В процессе стало ясно, что существует множество тем, имеющих значительную глубину с точки зрения программирования.
А в этом году мы начали снимать серию интервью под общим лейблом «DZ Online Tech» — теперь с акцентом на то, что под капотом.
Ну а так как всем лень смотреть видео, то, конечно, эти интервью расшифрованы, и сегодня я публикую первое — с Иваном Панченко из Postgres Professional. Кому интересен оригинал, вот он: (И кстати, не могу поклясться, что все серии выйдут в стенограмме, так что если понравилось, подписывайтесь на YouTube, там все выйдет раньше и гарантировано.
) Для любителей читать - расшифровка: Добрый день, Иван.
Postgres широко воспринимается как инструмент импортозамещения.
И самым известным драйвером его использования является идея «давайте заменим какую-нибудь западную СУБД на Postgres».
При этом известно, что у него довольно много собственных ценностей.
Я хотел бы кратко пройтись по ним.
Если мы выбираем не оглядываясь на «импорт – не импорт», а с чистого листа – почему? Добрый день.
Во-первых, большинство людей выбирают Postgres не из-за импортозамещения.
Понятно, что действительно существуют государственные меры и ограничения на ввоз иностранного ПО.
Postgres Pro есть в реестре, поэтому подходит для импортозамещения.
Фактически, во всем мире наблюдается тенденция все чаще выбирать Postgres. Мы видим только ее отражение.
Возможно, то, что мы выразили в импортозамещении, на самом деле является следствием каких-то более глубоких, фундаментальных процессов.
Postgres является зрелым.
Это хорошая альтернатива старым коммерческим базам данных.
Весь мир теперь понимает, что Postgres — это продукт того же класса, что и киты: Oracle, Microsoft SQL Server и DB2, последняя из которых почти забыта, но, тем не менее, это хороший продукт. Но, так или иначе, DB2 постепенно уходит с рынка, зато на нем присутствуют Oracle и Microsoft SQL. А Postgres — это нечто третье, что сейчас выходит на рынок в мировом масштабе.
Надо сказать, что он витал в воздухе уже давно — лет 10 назад, когда у Postgres была хорошая поддержка Windows. Когда в нем появилась репликация, это стало восприниматься; о ней стали говорить как о базе данных для бизнеса, промышленности и чего-то серьёзного.
Сейчас вы еще говорите в фильме «было два хороших, есть еще один хороший».
Но, вероятно, есть вещи, которые выдвигают его вперед и заставляют предпочитать его другим.
Да, таких вещей несколько.
Во-первых, Postgres — это продукт с открытым исходным кодом и специальной лицензией.
В то же время у него есть коммерческие клоны.
Один из них наш.
Но тот факт, что это продукт с открытым исходным кодом, сам по себе является большим преимуществом.
Вторая тема заключается в том, что Postgres — это база данных с широкими возможностями расширения.
Это также послужило драйвером его развития.
Надо сказать, что степень расширяемости Postgres — это именно то место, где наиболее заметен наш российский вклад. Последние 15-17 лет наша команда работала в основном над механизмами расширяемости.
Например, в Рамблере в 2000 году, где я впервые работал с нынешними коллегами в компании, мы использовали расширяемость Postgres, чтобы увеличить производительность службы новостей Рамблера в 30 раз.
Как? Мы программисты, владеющие языком C и умеющие читать документацию.
Эти две вещи позволили нам создать новый тип индекса для быстрого поиска по массиву, который выходит за рамки классической реляционной модели, но полезен.
В частности, в Рамблере замена лишнего соединения на массив, по которому можно искать по хитрому индексу, увеличила производительность в 30 раз.
Надо понимать, что в то время все контент-проекты Рамблера работали на машинах, мощность которых не превышала мощности современного смартфона: Pentium 2, 400 МГц, 500 МБ памяти.
Если повезет, Pentium 3 (он тогда появился) имеет частоту до 800 МГц.
На сервере может быть два таких процессора Pentium 3. И все это обслуживало миллионы запросов.
Понятно, что тогда пришлось серьезно оптимизировать код, иначе бы он не работал.
Расширяемость Postgres помогла.
Посидели, подумали и в приемлемые сроки, можно сказать за месяц, сделали то, что впоследствии стало основой всего, что сейчас есть в Постгресе, связанного с JSON и полнотекстовым поиском.
Благодаря этому в Postgres быстро добавили поддержку полуструктурированных данных.
Что это? Это, грубо говоря, ключ-значение.
В 2004 году мы создали расширение для Postgres под названием Hstore, позволяющее хранить информацию о ключах и значениях в одном поле базы данных.
В то время это еще не был JSON; это вошло в моду позже.
А потом был Hstore. Почему Hstore? Мы рассмотрели Perl, в котором есть хэш, и создали хеш с почти таким же синтаксисом в Postgres. Сначала эта штука существовала как отдельное расширение, затем ее закрепили в основном наборе того, что входит в Postgres. И она была столь же популярна.
То есть JSON обогнал его по популярности совсем недавно.
Получается, что вы в каком-то смысле положили конец этому глупому обсуждению SQL и noSQL, создав СУБД, обладающую свойствами того и другого одновременно.
В некотором смысле да.
Мы взяли от noSQL хорошее, а именно сравнительную гибкость, не потеряв транзакционность, не потеряв целостность данных и все то, что обычно происходит в обычных СУБД.
Итак, Хсторе.
Но Hstore был одноуровневым.
То есть хэш одноуровневый.
Это не JSON, а просто хеш.
Плюс массивы в Postgres были и до нас.
Мы сделали поддержку индексов, то есть появилась возможность быстрого поиска по тому, что входит в массивы и по тому, что лежит внутри Hstore, как по ключам, так и по значениям.
Это полезная вещь.
Люди начали использовать его по всему миру.
Затем появился JSON. Появилось оно недавно, в 2011-2012 годах в Postgres. Было три разные попытки реализовать это.
Потом все эти попытки были отброшены и сделаны по-другому.
Сначала JSON представлял собой просто текст, хранившийся в специальном поле.
Ваша команда создала JSON? Нет, наша команда сделала что-то важное для JSON. Когда JSON появился в Postgres, это было просто текстовое поле, и чтобы получить из него что-либо, JSON должен был каждый раз анализировать какое-то искомое значение.
Конечно, это было медленно, но позволяло обеспечить многоуровневое хранение данных.
Но такое текстовое поле не имеет особого смысла.
Например, в своих проектах я уже хранил полуструктурированные данные в текстовых полях, просто не называя их полем специального типа.
Но вопрос в том, что с этим JSON тоже нужно было эффективно работать.
И то, что мы уже сделали с нашей командой в 2014 году, — это JSON-B. Это быстрее за счет того, что оно уже разложено и проанализировано.
Разобрано так, что можно быстро получить значение по ключу.
Когда мы сделали JSON-B и добавили возможность поиска по индексам, он стал по-настоящему популярным.
ХОРОШО.
Возвращаясь к конкретным свойствам: что еще отличает Postgres от других СУБД и является поводом его использовать? Все, что мы так долго говорили о JSON, — это проявление гибкости Postgres. У него много мест, где его можно расширить.
Другая сторона гибкости — поддержка геоданных.
Точно так же, как создавались специальные индексы, например, для поиска в JSON, в массивах и в текстах, делались индексы для быстрого поиска в геоинформационных и пространственных данных примерно по одному и тому же месту.
Там мы тоже приложили к этому делу свою немаленькую российскую руку.
Результатом стал PostGIS — очень распространенный в мире способ работы с геоинформационными данными.
Разрабатывают ли пользователи расширения для Postgres для своих проектов? Это значительный объём его применения? Нет, естественно, это какой-то «крем» сверху.
Есть люди, которым это нужно, потому что их задача к этому сводится.
Это, прежде всего, универсальная база данных, которая отлично поддерживает все стандарты и наверняка подойдет практически для любых задач.
Если вы запускаете стартап, например, возьмите Postgres, вы не ошибетесь.
Потому что, во-первых, он функционально расширяем.
А во-вторых, если вы используете его открытую версию, то не становитесь заложником лицензии, которую вам необходимо приобрести.
Вам, как сотруднику коммерческой компании, наверное, не очень приятно это говорить? Это законы природы, которые нельзя нарушать.
Есть открытый исходный код и есть бизнес с открытым исходным кодом.
И это довольно необычная вещь, отличная от обычного бизнеса.
Но в будущем роль открытого исходного кода, вероятно, вырастет. По крайней мере, это видно по успеху Postgres и по надоедливой диаграмме Gartner о том, что база данных с открытым исходным кодом используется все чаще, и от нее никуда не деться.
Вы как компания, зачем вы нужны? Вот он с открытым исходным кодом: зашел, скачал и все нормально?
На самом деле я пошел и скачал его, но столкнулся с проблемой.
Рано или поздно люди сталкиваются с проблемой.
Понятно, что версия с открытым исходным кодом подойдет большинству пользователей.
У них не будет проблем, у них базы маленькие, они не вырастут. Но в некоторых случаях необходима помощь профессионала.
Раньше модель была простой.
В данном случае я говорю о Postgres, потому что разные продукты находятся на разных стадиях этого эволюционного пути.
Изначально Postgres был просто университетским проектом.
Люди не думали о деньгах; они были заинтересованы в решении проблемы.
Тогда это был волонтерский проект: люди делали это для себя.
В то же время они работали в некоторых компаниях, подобных нашей.
Ну а как вы приняли решение в Рамблере? Рамблер — хороший пример.
Мы сделали это, потому что нам это было нужно.
Мы вообще не заботились о бизнес-пользователях.
Нужна ли она кому-то еще или нет? Компании Postgres изначально начали появляться не в России, а в других странах.
Впервые такая компания возникла в Японии, пусть и на деньги Fujitsu. Туда было вложено довольно много.
И она начала разрабатывать что-то в Postgres и около-Postgres. Затем, довольно скоро после этого, в Англии появился второй квадрант (2nd Quadrant), а в Америке Enterprise DB. Это все компании, которые зарабатывают на Postgres. Все эти компании начинают с выполнения заказов.
Они делают. Индивидуальная разработка.
Заказная разработка на уровне СУБД.
Мы тоже этим занимаемся, и делали такие вещи, когда еще не были компанией, потому что расширяем Postgres. «Нам нужен полнотекстовый поиск, чтобы не только искать таким образом, но и правильно игнорировать наш французский акцент или наши немецкие умлауты.
Закончи это, мы тебе заплатим».
Или: «JSON — очень хорошая вещь.
Я бы хотел прикрепить к нему индекс.
И тогда наш портал бесплатных объявлений полетит чуть быстрее всех».
Это ребята, которые фактически финансировали разработку, платя отдельным разработчикам или, в некоторых случаях, заказывая некоторые функции, которые они хотели, у молодых, недавно появившихся компаний.
А затем постепенно стала возникать потребность в коммерческих версиях Postgres. Почему и откуда взялись эти коммерческие форки? Прежде всего надо сказать, что у Postgres настолько хитрая лицензия, которая легально позволяет делать из него коммерческий продукт. BSD-подобная лицензия.
Это вообще не GPL. Можно взять хоть тот же код, даже не внося в него никаких изменений, оставить там две строчки из лицензионного соглашения, добавить к нему еще что-то свое и написать, что это моя «БД Васи Пупкина» и я продаю это.
Выйти на рынок и продать хоть за миллиарды - пожалуйста, не важно.
Купит ли кто-нибудь «Вася Пупкин БД» у Васи Пупкина или нет – это отдельный вопрос.
Скорее всего нет. А если он привнесет в это что-то свое? И они начали это делать.
У нас есть картинка, где зеленые и красные флажки обозначают коммерческие и некоммерческие версии Postgres. Их довольно много.
Мы насчитали 40-50 штук.
Большинство из них, естественно, не имеют успеха: они вымирают и о них забывают. Например, некоторые крупные организации, такие как Amazon или Salesforce, могут сделать форк для себя.
Самыми известными коммерческими форками являются, конечно же, Greenplum и EnterpriseDB. Включая наш Postgres Pro, японский Fujitsu Enterprise Postgres. 
Британцы также недавно выпустили корпоративную версию Postgres. За что? Существуют специализированные форки, например Greenplum — база данных для массовых аналитических вычислений с высоким параллелизмом.
Они взяли Postgres лет десяти назад, сильно изменили планировщик, добавили туда работу с распределенными запросами, правда, потеряв транзакционную целостность.
Но для аналитических баз данных это не имеет значения: все уже есть, и необходимо собрать и правильно распределить запрос по серверам.
Они сделали Гринплум.
Эту вещь используют, в том числе, и в России.
В частности, Тинькофф Банк похвастался, что он у них есть.
Хорошая вещь, имевшая некоторый коммерческий успех, но отстававшая от open source из-за высокого уровня несовместимости.
Они очень сильно поменяли планировщик, сделали много хорошего, их, конечно, можно похвалить за это, но развитие open source пошло в другом направлении.
И здесь главное не переборщить.
Чем дальше вы отдаляетесь, тем сложнее потом слиться.
Первый пример — когда они создали версии Postgres с некоторыми специфическими функциями.
Это один из примеров того, почему возникают коммерческие компании.
Какие еще есть? Greenplum реализовал действительно важную функцию, которая сильно отодвинула Postgres в сторону.
При этом это уже не универсальный продукт, но он хорошо решает важную, востребованную задачу.
К другой группе форков относятся наши базы данных Postgres Pro и Enterprise. Последние, как ни странно, несмотря на всю свою американскую природу, мигрируют с Oracle. В Америке тоже переходят с Oracle, потому что за каждый «чих» платить дорого.
Не все этого хотят, и не всем есть чем платить.
Вот почему Enterprise DB предлагает услуги миграции Oracle по всему миру.
И для того, чтобы было проще сканировать, они пошли по пути реализации в Enterprise DB некоторых функций, которые есть в Oracle. Что такое наш PostgreSQL? Мы решили не идти по этому пути, хотя некоторые возможности Oracle тоже реализовали, например асинхронные автономные транзакции.
Но в долгосрочной перспективе мы не видим пути, по которому можно было бы следовать Oracle. Потому что «следование» означает, что вы всегда будете отставать, и вы все равно никогда не будете совместимы на 100%, и вам все равно придется постоянно доказывать, что вы хотя бы частично совместимы.
Это сложная проблема.
Хотя вы можете написать синтаксический анализатор для языка Oracle PSQL; слава богу, он синтаксически документирован, но очень строгой документации по его семантике вы не найдете.
Более того, для полной совместимости вам придется воспроизводить ошибку за ошибкой.
Попробуйте сделать это, а затем докажите, что это действительно так.
Мы поняли, что это на самом деле не решает полностью проблему миграции.
Мы решили, что лучше двигаться дальше.
Лучше просто делать лучший продукт. С другой стороны, нужно ли в такой картине обеспечивать совместимость на уровне полного покрытия, не говоря уже о «баге к багу»? Задача — покрыть условные 80% расходов при миграции.
Действительно так кажется, но на практике оказывается, что когда мигрируешь систему, это выглядит так: тебе дают готовую систему.
Это черный ящик, завернутый в черную бумагу и перевязанный черной веревкой.
Вы не знаете, что внутри.
Это 80% там или мало выходит? Очень часто бывает так, что его застроили методом «баг-баг» в 3 этажа, а строители первого этажа уже давно куда-то исчезли.
И поэтому, чтобы мигрировать на эту штуку, приходится заниматься реверс-инжинирингом — даже не для того, чтобы переписать, а для того, чтобы понять, работает она или нет. То есть если у вас идеальное тестовое покрытие — то да, можно говорить… Чего, конечно, никогда не бывает. .
Можно сказать: «Заменяем двигатель, проводим испытания.
Пройдено 100%, все проверено.
Идите».
На самом деле этого не происходит. Это идеальная ситуация.
И вот получается, что вы реализуете 80%, но остальные все равно пострадают, и вы заранее не знаете почему.
У миграции есть другое, многое более существенные проблемы.
Каждый продукт, каждая СУБД имеет свои преимущества.
Например, для Postgres это работает с JSON и массивами, о которых мы говорили.
Многие вещи, которые оптимально написаны таким образом в Oracle, оптимально пишутся в Postgres по-другому.
Поэтому если мигрировать «тупо», то вы получите минимально рабочее подмножество, совместимое и с тем, и с другим.
Вы не сможете воспользоваться ни старой базой данных, ни новой.
Скажем несколько слов о будущем.
Куда все это идет? Сможете ли вы убить всех конкурентов? Я не думаю, что мы убьем всех конкурентов.
В принципе, у нас такие хорошие, «ласковые» цели.
Мы пришли не убивать, а строить.
Наша цель — создать очень хорошую базу данных.
Предпочтительно лучшее.
А что это такое? Каков критерий этой доброты? Я сомневаюсь, что целью Microsoft является создание очень плохой базы данных.
Да, конечно, все к этому идут. Поэтому сейчас в мире баз данных есть некоторые тенденции.
А поскольку объемы данных растут быстрее всего остального, основной тенденцией в базах данных сейчас является их распространение.
Будут великолепны те, кто лучше сможет решить проблему распределенной базы данных.
С нами был Иван Панченко.
Спасибо Иван.
Спасибо.
Теги: #sql-сервер #postgres #postgresql #postgresql
-
Adobe Ищет Участие В Разработке
19 Oct, 24 -
Вы Используете Pgp (Gpg)?
19 Oct, 24 -
Playboy Выпустит Собственный Телефон
19 Oct, 24 -
Одноклассники Изменили Дизайн
19 Oct, 24
