Продолжим тему из публикации «Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap».

Сегодня визуализируем 15 мест где в России больше всего зданий. В этом нам поможет мой проект openstreetmap_h3 и PostgreSQL 15. На данный момент OpenStreetMap H3 единственное решение для импорта OSM данных партиционированных по H3 геоиндексу в PostgreSQL и Citus massive parallel processing. Сохраним данные в колоночное хранилище и посмотрим на план запроса для него.

В этой публикации мы будем агрегировать данные в большой таблице где нас интересуют для этих операций лишь два столбца и сможем извлечь пользу от этой модели данных на NVMe накопителе. Раньше я работал с колоночными базами данных AWS Redshift, Dremio, QuestDB и HeavyDB, но не смотря на их производительность, до функционала/протестированности и стабильности PostgreSQL им еще пока еще ох как далеко. Вот и отлично, попробуем получить все плюсы экосистемы PostgreSQL и колоночного хранилища citus. Вперед, к заветной цели на самых свежих версиях программ нашего аналитического стека!

Когда человек раньше говорил что он контролирует весь мир, то его обычно помещали в соседнюю палату с Бонапартом Наполеоном. Надеюсь, что эти времена остались в прошлом и каждый желающий может анализировать геоданные всей земли и получать ответы на свои глобальные вопросы за минуты и секунды. Я опубликовал Openstreetmap_h3 — свой проект, который позволяет производить геоаналитику над данными из OpenStreetMap в PostGIS или в движке запросов, способном работать с Apache Arrow/Parquet.

Первым делом передаю привет хейтерам и скептикам. То что я разработал — действительно уникально и решает проблему преобразования и анализа геоданных используя обычные и привычные инструменты доступные каждому аналитику и датасаенс специалисту без бигдат, GPGPU, FPGA. То что выглядит сейчас простым в использовании и в коде — это мой личный проект в который я инвестировал свои отпуска, выходные, бессонные ночи и уйму личного времени за последние 3 года. Может быть я поделюсь и предысторией проекта и граблями по которым ходил, но сначала я все же опишу конечный результат.

Первый пост не претендует на монографию, начну с краткого обзора...

Ноябрьский коммитфест принес немало интересного! Без лишних предисловий приступаем к обзору.

Самое интересное об июльском и сентябрьском коммитфестах ― в предыдущих статьях серии: 2023-07, 2023-09.

Общеизвестно, что PostgreSQL - крайне эффективная СУБД с богатой функциональностью. При этом не секрет, что PostgreSQL масштабируется только вертикально и её производительность ограничена возможностями одного сервера.

Написано много хороших постов, в которых сравнивают архитектуру монолитных и распределенных СУБД. К сожалению, обычно авторы ограничиваются теоретическим сравнением и не приводят конкретные цифры. Данный пост же наоборот основан на эмпирическом исследовании с использованием бенчмарка TPC-C, который является промышленным стандартом для оценки производительности транзакционных СУБД (On-Line Transaction Processing, OLTP).

Мы расскажем, когда именно одного Postgres'a становится мало, и какие возможны компромиссы между производительностью и надежностью. Для тех, кто не готов к компромиссам, мы покажем, что могут предложить такие распределенные СУБД, как CockroachDB и YDB.

Введение

Введение

Большую часть прошлого года я работал с Hexvarium. Базирующаяся в Атертоне, штат Калифорния, компания строит и управляет оптоволоконными сетями. В настоящее время у них есть несколько сетей в районе залива, но у них есть планы по расширению в США.

Моя роль заключается в управлении платформой данных, которая содержит 30 миллиардов записей примерно из 70 источников информации. Эти данные используются инженерами, разрабатывающими оптимальные планы развертывания оптоволоконной сети с помощью LocalSolver. Далее приведен пример одного из таких планов.

Привет, Хабр! В статье расскажу о том, с какими трудностями можно столкнуться при разработке ORM на PHP и поделюсь опытом по их преодолению.

Рассказывать буду только о том, о чём знаю сам. У вас может быть абсолютно другое мнение. Поэтому если вы нашли ошибку или хотите обсудить — свяжитесь со мной.

Вначале мы делали документацию в Word, потом в Google Docs, потом в Confluence, потом была попытка написать openapi-спецификацию для API вручную, но увидев сколько всего там нужно было писать - бросили эту затею.

Нужно было вести документацию в знакомом отрасли формате для растущего (в количестве сервисов) API, и делать это максимально "подручно".

У меня родилась статья в продолжение серии хороших статей:

Перейти с Linux на macOS и не сойти с ума

7 причин почему вам не стоит переходить на Mac, или как справиться с этой демонической машиной

Я, старый дурак пользователь Windows (26 лет стажа, ну да, с 1997 г.) решил купить макбук. Вот этот, предпоследний, стильный-модный-молодежный на процессоре M1 Pro. Нафига, а главное зачем - вопрос риторический и не предполагающий ответа (захотелось). Как его можно настроить, чтобы заскорузлому виндузятнику стало возможно использовать этот чудо-компьютер с яблоком без очень сильной боли в одном месте, я попытаюсь написать в этой заметке. Хотел бы я, чтобы полгода назад мне на глаза попалась такая!

Привет! В статье поделюсь, как инструмент автоматического рефакторинга Rector помогает обуздать легаси и автоматизировать обновление PHP проектов и пакетов, чтобы процесс проходил эффективнее и малой кровью. 

Статья написана на основе доклада с PHP Russia 2022.

Ещё одна статья на избитую тему? Да! Потому что за два часа поиска не нашёл ни одной, по которой можно было пройтись от и до и получить работающее окружение.

Шагов, на самом деле, немного, все очень простые, нужно лишь...

BitTorrent — протокол загрузки и распространения файлов через Интернет. В отличие от традиционных отношений клиент/сервер, когда загрузчики подключаются к центральному серверу (например, для просмотра фильма на Netflix или загрузки веб-страницы), участники сети BitTorrent, называемые одноранговыми узлами, загружают фрагменты файлов друг с друга. Это то, что делает BitTorrent одноранговым протоколом. Исследуем, как он работает, и создадим собственный клиент, который сможет находить одноранговые узлы и обмениваться с ними данными.

Я часто заморачиваюсь на тему минимизации размера своих GUI приложений. Прошлая моя статья была про Nuklear. Но сейчас захотелось более современных технологий. Чтоб HTML5, CSS3 и PHP. Чтоб приложение ни от чего не зависело, т.е. построено по принципу "всё включено". И чтоб конечный размер приложения не превысил 2 МБ. Получится ли?

В Linux я часто пользуюсь утилитой df. Мне её очень не хватает в Windows, а искать аналоги лень. Так что было сделано волевое решение сделать свою, на РНР 5, с бутстрапом и JQuery.

В июне прошлого года вышла первая версия программы Organic Maps - бесплатных мобильных карт для Android и iOS с открытым исходным кодом. Об этом событии я опубликовал небольшую заметку на Хабре. Весь год шла интенсивная разработка, а число установок превысило 100 тысяч. Я решил взять небольшое интервью у разработчиков Organic Maps и обсудить с ними итоги года работы и планы на будущее.

Комментарий автора: Основная цель доклада — рассказать про методы построения инфраструктуры (Configuration Synchronization/Immutable infra) и сравнить их. Ansible используется как пример одного из инструментов синхронизации конфигурации. С точки зрения автора мир движется в сторону immutable infrastructure и в докладе приводятся аргументы разъясняющие позицию автора. И так как мир движется в сторону immutable infrastructure, то учить инструменты использующие подход синхронизации конфигураций может быть не самым лучшим использованием времени. Повторю еще раз — доклад не про инструменты, а про подходы и принятие решения “от-проблемы”, а не “от-инструмента”

Disclaimer: Этот доклад сложен тем, что готовится под российскую аудиторию, которая работает в несколько специфических условиях. Мы потрогаем все эти вещи во время презентации. В России специфичное использование инфраструктуры, потому что народ в основном живет не на Amazon. Есть компании, которые и там живут, но их мало. И это является ограничением. Это стоит учитывать во всех докладах, связанных с раскаткой инфраструктуры, чтобы не говорить: «Ребята, поехали в облако, в AWS все будет отлично» и тут сидит толпа людей, которые туда поехать не могут. Российская аудитория кажется очень специфичной. И те доклады, которые заходят в Европе, в России не всегда заходят. Возможно, это связано с особым восприятием данной аудитории.