Pull to refresh
58
0
Михаил Кузьмин @mkuzmin

User

Send message

Elasticsearch как NoSQL база данных

Reading time 8 min
Views 60K
Может ли поисковый сервер Elasticsearch использоваться в качестве NoSQL базы данных? Положительный ответ позволит рассмотреть его различные свойства, в том числе и те, от реализации которых он отказался, чтобы стать одним из самых гибких, производительных и масштабируемых поисковых движков. Но для ответа на этот вопрос стоит сначала определиться с самим термином NoSQL, так как в зависимости от контекста он может трактоваться по-разному.

Что же все-таки такое NoSQL?


Разработчики NoSQL дают такое определение: база данных следующего поколения, характеризующаяся отказом от реляционности, распределенностью, открытостью исходных текстов и горизонтальной масштабируемостью. Назвать это определение точным, увы, нельзя.

Дело в том, что речь идет совсем не об SQL. Поясним. Язык запросов Hive явно был вдохновлен SQL. Это же можно сказать и о языке Esper, хоть он работает и не с потоками, а с отношениями. Интересна история PostgreSQL — изначально он назывался Postgres, в качестве языка запросов использовал Quel и являлся ORDBMS, а сегодня PostgreSQL обладает многими функциями, которые позволяют ему быть документноориентированным хранилищем.

В данном случае речь идет не о ACID — в определении NoSQL о транзакциях ничего не говорится. Hyperdex — это база NoSQL, которая стремится обеспечивать ACID-транзакции. MySQL, несомненно, является базой SQL и в своей истории имеет сомнительные интерпретации на тему, что же на самом деле означает ACID.
Читать дальше →
Total votes 30: ↑27 and ↓3 +24
Comments 10

saneex.c: try/catch/finally на базе setjmp/longjmp (C99) быстрее стандартных исключений C++¹

Reading time 19 min
Views 12K

Пока писал эту сугубо техническую статью, Хабр успел превратиться в местное отделение ВОЗ и теперь мне даже стыдно ее публиковать… но в душе теплится надежда, что айтишники еще не разбежались и она найдет своего читателя. Или нет?




Меня всегда восхищала стандартная библиотека Си, да и сам Си — при всей своей минималистичности от них так и веет духом тех самых первых красноглазиков хакеров. В черновике первого официального стандарта (ANSI C, он же C89, он же ANS X3.159-1989, он же, позднее, C90 и IEC 9899:1990) определяется 145 функций и макросов, из них около 25 — это вариации (ввиду отсутствия в языке перегрузок), а 26 чисто математических. K&R во второй редакции² приводят 114 функций (плюс математические), считая остальные за экзотику. В черновике³ C11 функций уже 348, но больше сотни — математика, а еще штук 90 это «перегрузки». А теперь посмотрим на Boost, где одних только библиотек — 160. Чур меня…


И среди этой сотни-полутора функций всегда были: обработка сигналов, вариативные функции (которые до интерпретируемого PHP дошли 25 лет спустя, а в Delphi, бурно развивавшемся одно время, их нет до сих пор) и порядка 50 строковых функций вроде printf() (м-м-м… JavaScript), strftime() (…) и scanf() (дешевая альтернатива регуляркам).



А еще всегда были setjmp()/longjmp(), которые позволяют реализовать привычный по другим языкам механизм исключений, не выходя за рамки переносимого Си. Вот о них и поговорим — Quake World, стеки, регистры, ассемблеры и прочая матчасть, а вишенкой будет занятная статистика (спойлер: Visual Studio непостоянна, как мартовский заяц, а throw saneex.c в два раза быстрее всех).


Текста много, не порежьтесь!
Total votes 43: ↑42 and ↓1 +41
Comments 44

Современные накопители очень быстры, но плохие API это не учитывают

Reading time 11 min
Views 14K


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

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

Поразмышляв о причинах этой неувязки, я понял, что в основном устойчивость таких заблуждений вызвана следующим: даже если они проверяли свои предположения при помощи бенчмарков, то данные показывали их (кажущуюся) истинность.

Вот самые распространённые примеры таких заблуждений:

  • «Вполне нормально скопировать память здесь и выполнить эти затратные вычисления, потому что это сэкономит нам одну операцию ввода-вывода, которая была бы ещё более затратной».
  • «Я проектирую систему, которая должна быть быстрой. Поэтому она должна находиться в памяти».
  • «Если мы разобьём эти данные на несколько файлов, то выполнение будет медленным, поскольку возникнут паттерны произвольного ввода-вывода. Нам нужно оптимизировать выполнение под последовательный доступ и осуществлять считывание из одного файла».
  • «Прямой ввод-вывод очень медленный. Он подходит только для очень специализированных областей применения. Если у тебя нет собственного кэша, ты обречён».

Однако если изучить спецификации современных NVMe-устройств, то мы увидим, что даже в потребительском классе это устройства с задержками, измеряемыми в единицах микросекунд, и пропускной способностью в несколько ГБ/с, поддерживающие несколько сотен тысяч произвольных IOPS. Так в чём же нестыковка?
Читать дальше →
Total votes 46: ↑42 and ↓4 +38
Comments 40

ООП мертво, да здравствует ООП

Reading time 18 min
Views 58K
image

Источники вдохновения


Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).
Читать дальше →
Total votes 55: ↑50 and ↓5 +45
Comments 48

Domain-driven design: рецепт для прагматика

Reading time 21 min
Views 66K

Почему к DDD обычно подходят не с той стороны? А с какой стороны надо? Какое отношение ко всему этому имеют жирафы и утконосы?

Специально для Хабра — текстовая расшифровка доклада «Domain-driven design: рецепт для прагматика». Доклад был сделан на .NET-конференции DotNext, но может пригодиться не только дотнетчикам, а всем интересующимся DDD (мы верим, вы осилите пару примеров кода на C#). Видеозапись доклада также прилагается.
Total votes 45: ↑44 and ↓1 +43
Comments 29

Как мы забили на асинхронность при походах на бэкенды

Reading time 6 min
Views 26K
threads

Под напором появления новых асинхронных неблокирующихся фреймворков может показаться, что блокирующиеся вызовы — это пережиток прошлого, и все новые сервисы нужно писать на полностью асинхронной архитектуре. В этом посте я расскажу, как мы решили отказаться от неблокирующих асинхронных вызовов бэкендов в пользу обычных блокирующих.
Читать дальше →
Total votes 40: ↑30 and ↓10 +20
Comments 46

Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности

Reading time 9 min
Views 61K

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).


Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.


Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.


Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).


Total votes 77: ↑76 and ↓1 +75
Comments 73

Борьба с грязными побочными эффектами в чистом функциональном JavaScript-коде

Reading time 25 min
Views 22K
Если вы пробуете свои силы в функциональном программировании, то это значит, что вы довольно скоро столкнётесь с концепцией чистых функций. Продолжая занятия, вы обнаружите, что программисты, предпочитающие функциональный стиль, похоже, прямо-таки одержимы этими функциями. Они говорят о том, что чистые функции позволяют рассуждать о коде. Они говорят, что чистые функции — это сущности, которые вряд ли будут работать настолько непредсказуемо, что приведут к термоядерной войне. Ещё вы можете узнать от таких программистов, что чистые функции обеспечивают ссылочную прозрачность. И так — до бесконечности.

Кстати, функциональные программисты правы. Чистые функции — это хорошо. Но есть одна проблема…


Автор материала, перевод которого мы представляем вашему вниманию, хочет рассказать о том, как бороться с побочными эффектами в чистых функциях.
Читать дальше →
Total votes 36: ↑35 and ↓1 +34
Comments 18

Корпоративный синдром

Reading time 13 min
Views 72K
— Идея с айфонами — полное говно. — начал встречу Сергей.

— Извините, Сергей, я не ослышалась? — недобро прищурившись, спросила Светлана Владимировна.

— Не ослышались, Светлана Владимировна. — кивнул Сергей. — Айфоны придется отменить, иначе этот бедлам дебильный будет не остановить.

Татьяна, видимо, не ожидавшая такого развития событий, сидела с круглыми глазами. Этими круглыми глазами она и уставилась на Сергея. Впрочем, как и остальные господа топ-менеджеры.

— И это говорит человек, больше всех радеющий за развитие? — с ехидной улыбкой спросила Марина, директор по качеству?

— Ты бы молчала лучше… — вздохнул Сергей.

— А ты мне рот не затыкай! — улыбка с лица Марины исчезла. — Сам предлагаешь эти айфоны, сам потом их говном называешь. Как баба капризная.

— Идея не Сергея, а моя. — твердо проговорила Светлана Владимировна. — Сергей, я жду объяснений. И выбирайте, пожалуйста, выражения, вы не с программистами разговариваете. Да и с программистами так разговаривать не стоит.
Читать дальше →
Total votes 226: ↑194 and ↓32 +162
Comments 254

Гетерогенная конкурентная обработка данных в реальном времени строго один раз

Reading time 34 min
Views 14K

Конкурентная сосиска


Аннотация


Обработка данных в реальном времени ровно один раз (exactly-once) — задача крайне нетривиальная и требующая серьезного и вдумчивого подхода на всей цепочке вычислений. Некоторые даже считают, что такая задача невыполнима. В реальности хочется иметь подход, обеспечивающий отказоустойчивую обработку вообще без каких-либо задержек и использование различных хранилищ данных, что выдвигает новые еще более жесткие требования, предъявляемые к системе: concurrent exactly-once и гетерогенность персистентного слоя. На сегодняшний день такое требование не поддерживает ни одна из существующих систем.


Предложенный подход последовательно раскроет секретные ингредиенты и необходимые понятия, позволяющие относительно просто реализовать гетерогенную обработку concurrent exactly-once буквально из двух компонент.


Введение


Разработчик распределенных систем проходит несколько стадий:


Стадия 1: Алгоритмы. Здесь происходит изучение основных алгоритмов, структур данных, подходов к программированию типа ООП и т.д. Код исключительно однопоточный. Начальная фаза вхождения в профессию. Тем не менее, достаточно непростая и может длиться годами.


Стадия 2: Многопоточность. Далее возникают вопросы извлечения максимальной эффективности из железа, возникает многопоточность, асинхронность, гонки, дебагинг, strace, бессонные ночи… Многие застревают на этом этапе и даже начинают с какого-то момента ловить ничем не объяснимый кайф. Но лишь единицы доходят до понимания архитектуры виртуальной памяти и моделей памяти, lock-free/wait-free алгоритмах, различных асинхронных моделях. И почти никто и никогда — верификации многопоточного кода.


Стадия 3: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.

Читать дальше →
Total votes 23: ↑23 and ↓0 +23
Comments 6

Domain Driven Design на практике

Reading time 12 min
Views 264K
Эванс написал хорошую книжку с хорошими идеями. Но этим идеям не хватает методологической основы. Опытным разработчикам и архитекторам на интуитивном уровне понятно, что надо быть как можно ближе к предметной области заказчика, что с заказчиком надо разговаривать. Но не понятно как оценить проект на соответствие Ubiquitous Language и реального языка заказчика? Как понять, что домен разделен на Bounded Context правильно? Как вообще определить используется DDD в проекте или нет?

Последний пункт особенно актуален. На одном из своих выступлений Грег Янг попросил поднять руки тех, кто практиукует DDD. А потом попросил опустить тех, кто создает классы с набором публичных геттеров и сеттеров, располагает логику в «сервисах» и «хелперах» и называет это DDD. По залу прошел смешок:)

Как же правильно структурировать бизнес-логику в DDD-стиле? Где хранить «поведение»: в сервисах, сущностях, extension-методах или везде по чуть-чуть? В статье я расскажу о том, как проектирую предметную область и какими правилами пользуюсь.
Читать дальше →
Total votes 32: ↑28 and ↓4 +24
Comments 18

Управление разработкой технологически сложных интернет-приложений в условиях острой нехватки времени

Reading time 45 min
Views 16K

Вступление


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


В заметке так же рассматривается больной вопрос трудностей с выплатой зарплаты и как их можно эффективно решать.

Читать дальше →
Total votes 31: ↑29 and ↓2 +27
Comments 34

Четыре типажа программистов

Reading time 17 min
Views 213K

Привет.


Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.

Читать дальше →
Total votes 258: ↑237 and ↓21 +216
Comments 548

Прагматичное функциональное программирование

Reading time 5 min
Views 15K

Движение к функциональному программированию началось всерьез примерно десятилетие назад. Мы видели как такие языки как Scala, Clojure и F# стали привлекать внимание. Это движение было больше чем просто обычное восхищение «О, круто, новый язык!». Было что-то действительно побуждающее это движение — или мы так думали.

Читать дальше →
Total votes 31: ↑26 and ↓5 +21
Comments 100

Заблуждения Clean Architecture

Reading time 15 min
Views 406K
Превращаем круги в блоки

­­ 


На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.

Читать дальше →
Total votes 58: ↑56 and ↓2 +54
Comments 203

Логика английских времен

Reading time 6 min
Views 71K
Изучавшие или изучающие английский язык знают, каким страшным может казаться множество английских временных форм глаголов.
Всего в английском 12 временных форм. А в русском-то, на первый взгляд, всего 3, и как их связать с английскими, для новичка может быть совершенно не понятно.
Читать дальше →
Total votes 196: ↑173 and ↓23 +150
Comments 202

Что делать с чужими долгами?

Reading time 16 min
Views 34K
Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код

Цель этой публикации — поделиться опытом работы над проектом со сложной историей и тяжёлым наследием. После ухода из очередного т.н. «стартапа», я решил что хочу попробовать новых ощущений: enterprise, legacy, etc. Для этого взялся за работу над корпоративным приложением для транснационального концерна. Разработка на тот момент шла уже третий год, приложение пережило несколько поколений разработчиков, но стабильного релиза так и не было.

Полагаю публикация будет полезной:

  • разработчикам принимающим аналогичное решение, чтобы взвесить за и против
  • менеджерам «непростых» проектов, чтобы лучше понять причины и следствия технических проблем
  • и, конечно, просто любопытствующим

Затрагиваемые в статье вопросы:

  • Низкая компетенция разработчиков, и что с этим можно поделать?
  • Какие аргументы убедительны в глазах заказчика для нефункциональных изменений в проекте?
  • Почему работа аналитиков и QA очень важна с точки зрения разработки в частности и для проекта в целом?

Читать дальше →
Total votes 88: ↑85 and ↓3 +82
Comments 76

Эффективное внедрение зависимостей при масштабировании Ruby-приложений

Reading time 5 min
Views 12K


В нашем блоге на Хабре мы не только рассказываем о развитии своего продукта — биллинга для операторов связи «Гидра», но и публикуем материалы о работе с инфраструктурой и использовании технологий из опыта других компаний. Программист и один из руководителей австралийской студии разработки Icelab Тим Райли написал в корпоративном блоге статью о внедрении зависимостей Ruby — мы представляем вашему вниманию адаптированную версию этого материала.
Читать дальше →
Total votes 20: ↑18 and ↓2 +16
Comments 25

Свойства вертикали корпоративной власти

Reading time 7 min
Views 67K
В Яндексе – идеальные для ИТ отцы-основатели… а какую позитивную книгу о них и об идеологии Яндекса Соколов-Митрич написал… Но что в Яндексе сложилось за несколько лет «внизу»? В этом посте последняя ссылка показывает – полный мрак.
Второй пример – Магнитом управляет такой умный и правильный Сергей Галицкий (почитайте его интервью), но «внизу» творится какой-то ад: «Мы не рабы» кричат его сотрудники.

Почему так? Что же за злой рок преследует большие компании?

Давайте для упрощения абстрагируемся от того, что наверх лезут далеко не лучшие, и рассмотрим вертикаль власти в Компании из нормальных людей.

Даже в этом идеальном случае у неё имеются, причем со временем усиливаются, следующие негативные свойства:

1. Усиление строгости при движении приказов сверху-вниз.
2. Положительная обратная связь и искажение отчетности при движении информации снизу-вверх.
3. Уменьшение взаимопонимания с ростом количества промежуточных звеньев между сотрудниками.

Далее рассмотрим их подробнее и сформулируем:

4. Советы сотрудникам, идущим работать в большие компании.
5. Своё собственное скромное мнение, почему Яндекс всё ещё хорош на фоне многих других.


Движение сверху-вниз приказов и всего прочего. Вы же не ожидали увидеть здесь другую картинку?
Читать дальше...
Total votes 20: ↑19 and ↓1 +18
Comments 19

Объясняя необъяснимое

Reading time 11 min
Views 60K
Друзья, мы с радостью продолжаем публикацию интересных материалов, посвященных самым разнообразным аспектам работы с PostgreSQL. Сегодняшний перевод открывает целую серию статей за авторством Hubert Lubaczewski, которые наверняка заинтересуют широкий круг читателей.



Одна из первых вещей, которую слышит новоиспеченный администратор баз данных – «используй EXPLAIN». И при первой же попытке он сталкивается c непостижимым:

                                                        QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=146.63..148.65 rows=808 width=138) (actual time=55.009..55.012 rows=71 loops=1)
   Sort Key: n.nspname, p.proname, (pg_get_function_arguments(p.oid))
   Sort Method: quicksort  Memory: 43kB
   ->  Hash Join  (cost=1.14..107.61 rows=808 width=138) (actual time=42.495..54.854 rows=71 loops=1)
         Hash Cond: (p.pronamespace = n.oid)
         ->  Seq Scan on pg_proc p  (cost=0.00..89.30 rows=808 width=78) (actual time=0.052..53.465 rows=2402 loops=1)
               Filter: pg_function_is_visible(oid)
         ->  Hash  (cost=1.09..1.09 rows=4 width=68) (actual time=0.011..0.011 rows=4 loops=1)
               Buckets: 1024  Batches: 1  Memory Usage: 1kB
               ->  Seq Scan on pg_namespace n  (cost=0.00..1.09 rows=4 width=68) (actual time=0.005..0.007 rows=4 loops=1)
                     Filter: ((nspname <> 'pg_catalog'::name) AND (nspname <> 'information_schema'::name))

Что бы это могло значить?
Читать дальше →
Total votes 33: ↑31 and ↓2 +29
Comments 23

Information

Rating
Does not participate
Location
Ульяновск, Ульяновская обл., Россия
Registered
Activity