Pull to refresh

Comments 46

Но в Санкт-Петербурге бывает очень холодно зимой.

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

Нужно учитывать, что в Питере очень влажный климат и соответственно мороз воспринимается гораздо острее, как собственно и жара.
UFO just landed and posted this here
Могу сказать по себе, что находясь в Северной осетии с +37 в тени, я не потел вообще, а только чувствовал тепло на коже, при этом в Таганроге при +30 я уже сильно потел, т.к. дикая влажность из-за моря.
И отец мне рассказывал, что во время службы в забайкалье он спокойно переносил гораздо более сильные морозы по сравнению с центральной частью России, т.к. воздух был сухой.

Был как-то в спб в декабре. По термометру было где-то 0-+2 градуса, я ходил в термобелье и ватных штанах, и все равно через полчаса прогулки становилось капец как холодно.

Да, только в Питере еще и любит дуть холодный ветер :). В сочетании с высокой влажностью и температурой до -25 это с непривычки переносится очень тяжело.
И благодаря той же влажности, погода меняется плавно, в отличии от внутриконтинентального климата, так что сильной жары или мороза почти нету.
Интересно было бы узнать, что умеет или какие преимущества дает самописная СУБД по сравнению с готовыми решениями.
Все движки кастомно заточены под свои задачи. И просто эффективнее (обычно), чем более универсальные решения.
Это я понимаю, но я имел ввиду конкретно VK, насколько эффективнее или какой функционал они добавили. Тут много ньюансов. Просто когда слышишь, что один из крупнейших сайтов в интернете работает на PHP + MySQL, сразу понимаешь что это не совсем так.
И я конкретно про ВК. Разных типов баз/движов несколько десятков видов. Каждый делается под конкретные задачи + оптимально встраивается в общую инфраструктуру.
Правильно я понимаю, что «кастомная СУБД» это просто определенным образом подточенный MySQL?
Нет, как правило, движки имеют свои структуры данных, которые заточены под конкретные задачи. Есть и СУБД общего назначения, но она не имеет отношения к MySQL и не очень широко используется.
То есть, это даже и не реляционная СУБД со своими обычными качествами?
Вы можете сами почитать о том, что умеют и что не умеют разные движки. Как правило, они поддерживают набор операций, которые нужны для работы существующих фич ВК. Обычно нет ни транзакций ни изменяемой схемы. Примеры:

Друзья: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Friends.wiki

Списки: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Lists.wiki

Фото, Документы, и т.д: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Storage.wiki
Ещё немаловажно, что все сишные движки умеют работать по UDP, что важно, когда у вас много серверов, иначе довольно значимая часть памяти на сервере расходуется под поддержание информации о TCP соединениях в ядре, буферах, и т.д.

Неоднозначный вопрос. Когда-то давно был удивлен, что Alibaba со своими дикими нагрузками живет на MySQL и не кашляет.
Тут возникает вопрос, так ли плохи "универсальные" решения.

Мне кажется, тут дело не в преимуществах. Проблема в том, что все сторонние решения имеют один фатальный недостаток.
На большом масштабе, если вы смогли написать свою специализированную базу данных для, например, сообщений, которая требует на 30% меньше ресурсов, то вам вместо условно 1000 серверов нужно будет 700, то есть на 300 штук меньше. Это экономия в миллионы долларов, так что обычно затраты на разработку в таком случае оправданы. Если у вас все помещается в 10 серверов и вы пишете самописную базу, то, возможно, это и правда будет время, потраченное впустую.

Простите мне мою оплошность, я забыл что на хабре каждый второй — Шелдон Купер*. Впредь, во избежание недоразумений, я все свои шутки буду помечать курсивом и делать сноску** — дабы не вводить в заблуждение писателей, читателей и комментаторов.




*Шутка.
**Шутка встроенная в шутку — одновременно рекурсия и самоирония.

А сколько будет стоить ее создание и поддержка? Как эти цифры соотносятся со стоимостью железа? Был проведен анализ и на его основе принято бизнес-решение?

300 серверов тоже надо поддерживать. Вы должны это учитывать так же при анализе. А так математика в целом простая. Что бы написать кастомную СУБД под задачу много людей не надо, достаточно человека 2-3. Кушать допустим они будут сумарно баксов 150 в час. 300 серверов предположим что кушать будут баксов 60 в час (предположим что у нас 300 штук каких m4.xlarge).

Предположим что разработка СУБД в целом займет месяц-два работы и потом затраты на поддержку оной будут составлять уже каких-нибудь $15/h (типа часов 16 часов в месяц например). Итого инвестиция окупится через каких-нибудь месяцев 6.

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

Понятно что если вы просто вася пупкин — не надо вам делать свои СУБД. Разве что как хобби.

p.s. я все ж подозреваю что кушать эти разработчики будут чуть меньше.

Можем предложить, что серваки стоят в нашем ДЦ, и кушают 5$ час, а разработчики выкатили mvp за два месяца, а потом сказали, что надо допиливать еще года два и команда нужна человек 6-10, которую надо хантить на особые условия, ибо БД не каждый сделает.
Тогда цифры другие.
Не думаю, что оно продуктивно, представлять сферических коней.


Клево было бы услышать экономическое обоснование от разработчиков. Ну или действительно дело с "фатальным недостатком".

Здесь стоит учесть, что сервера обычно помощнее, чем m4.xlarge, я бы считал, что на каждом хотя бы по 16 логических CPU (8 физических ядер), а то и больше. Плюс разработчик каждого движка обычно только один и кушает он только в рабочее время, и все-таки немного поменьше :).

Грубо говоря, даже если мы считаем цены амазона завышенными вдвое, то выходит 300$ в час против не более 25$ в час одного разраба (сервера на ночь не выключаем, потому что это сервера с данными). Такое окупится даже если разработка займет 300/25=12 месяцев.
кушает он только в рабочее время

Я и считал 160 часов в месяц.


и все-таки немного поменьше

Суть была не в том что бы конкретные цифры обсудить, а в простом соотношении и времени окупаемости. cost/benifit анализ. Подставляя свои цифры мы можем прикинуть что и как.


Например Вася пупкин начитался статей о том как люди делают всякие кафки, касандры и прочие кликхаусы, и подумал "а чем я хуже, я ж тоже могу!". И введение кастомного решения у него затратит его времени на $10K а сэкономит он $100 в месяц, окупаемость ~10 лет. Вместо этого инвестировать время можно в другие вещи.


А вот если вы фэйсбук со своими датацентрами, и у вас все на php, то выгодно нанять команду высококвалифицированных C/C++ разработчиков что бы они вам на LLVM JIT компилируемый язык нарисовали, который позволит вам в 2-3 раза уменьшить нагрузки на железо (вот ту миллионы) +, поскольку у вас контроль за языком — позволят ввести новые фичи в язык, которые существенно упростят тот же статический анализ (array shapes, type aliases).


Ну то есть помимо очевидного бенифита в виде сокращения издержек на сервера, мы имеем косвенные бенифиты.


ну и да, реально довольно часто хочется что-то маленькое, специализированное и скучно. А потом уже под это дело можно и бенифиты придумать.


Вспомните такое приложение как маскарад. Там внутри очень даже кастомное решение которое пилилось насколько я помню больше года явно, как хобби. А потом хакатончик, чуть допилить и вот вас уже покупает фэйсбук.

За 2 месяца разработать субд?! Я конечно все понимаю, но как то очень оптимистично. А тестирование? А затраты на внедрение? И это ещё не факт что вообще взлетит. А если не взлетит, то какие будут затраты на возврат к старой субд? Да и поддержка у вас выглядит очень оптимистично. Разве что они наняли гениев, которые за два месяца написали весь функционал. Как по мне то это очень сложные вопросы
Я конечно все понимаю, но как то очень оптимистично.

специализированная СУБД, под конкретную задачу. Это не база данных общего назначения. Потому да, не вижу ничего страшного в 2-х месяцах.


А тестирование? А затраты на внедрение?

Вы можете внедрять новую систему планомерно, получая профит постепенно и тестируя в реальных условиях. Это существенно упрощает вопрос.


И это ещё не факт что вообще взлетит.

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


Разве что они наняли гениев, которые за два месяца написали весь функционал.

Решение после обкатки было выложено в опенсурс как раз что бы уменьшить и эти издержки (хотя сам факт выкатки в опенсурс это тоже дорогое удовольствие).


Как по мне то это очень сложные вопросы

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


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


У многих компаний существует такая практика. Найм людей тоже штука дорогая.

специализированная СУБД, под конкретную задачу.

Людей смущает громкая аббревиатура СУБД, как я понимаю. С тем же успехом можно было назвать это оптимизированным мемкэшем, с прозрачной записью на диск, так?

Ну тип того. Яркий пример такого простого специализированного решения — beanstalkd. Ну или вот.

Большинство движков — это что-то типа Redis, не memcached. Но СУБД, конечно, супер громко такое называть :)

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


Возьмите тот же angular — его пилили в гугле как хобби. А сегодня это один из самых популярных фреймворков. Или react — его так же пилили в facebook годами перед тем как зарелизить. Тот же graphql это так же был внутренний проект.


nginx — писался под рамблер, и стал популярным решением так же далеко не сразу и был намного проще в начале своего пути. Кафка так же пилится с 11-ого года, но из всех щелей она лезет только последние год-два.


ClickHouse так же пилится с 2009-ого года, и на тот момент когда начинали пилить только только появились сырые хадупы и касандры. Потому на тот момент рисков явно было меньше а профита явно было больше.

Ну и да, в некоторых ситуациях смена модели данных и разработка эффективного стораджа под эту модель единственный способ вписаться в нефункциональные требования. Благо обычно хватает существующих моделей (документы, графы, колонки)
перехал из Петербурга в Подмосковье и теперь только и мечтаю вернуться обратно.
А есть еще где почитать про структуру VK?
В принципе, ощутимая часть инфраструктуры VK была выложена Павлом Дуровым в open source вместе с документацией.


Можно ссылку?

но это выглядит как заброшенный проект

4 года, может ещё очухается, раз про него рассказывают
Это скорее как «слепок» на тот момент, который приведен скорее для желающих ознакомиться.
С тех пор развитие убежало далеко вперед, но пока, увы, не до планов по актуализации и поддержанию публичной версии.
Простите за тупой вопрос, а VK вообще сейчас развивается?

Заходил как-то на странички знакомых, последние апдейты у многих 5-летней давности, такое ощущение что надоело всем. С Одноклассниками аналогично, когда-то был бум интереса, потом затихло все.
Сам тоже давно не пользуюсь.
А чего на апреле 2017 года остановились?
По SimilarWeb уже на 8 месте в мире по посещаемости, а не на 5.
Спасибо. Интересно, с чем связан такой волнообразный график, сезон отпусков что ли? (или школьных каникул?;)

Мне тоже кажется, что VK сдает позиции. И вообще, все социалки проиграли безнадежно фейсбуку. Сколько бы я не заходил в VK, он просто не выдает мне ничего интересного из жизни друзей. Может быть у них нет никаких событий, а может быть алгоритм генерации ленты ущербный. Потому что если подписаться на группу, в которой много сообщений в день (такая как Мотомосква), то все лента будет забита сообщениями из Мотомосквы, в которых почти невозможно увидеть случайно затершийся пост от друзей.


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


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


Прошу прощения у сотрудников Контакта, но ведь действительно, сложно понять, зачем продолжать пользоваться вашим сайтом.

Only those users with full accounts are able to leave comments. Log in, please.