Comments 46
Но в Санкт-Петербурге бывает очень холодно зимой.
По-моему, разница с Подмосковьем незначительная. Мне больше в СПб не нравились более пасмурная погода и частые дожди, если говорить о климате.
И отец мне рассказывал, что во время службы в забайкалье он спокойно переносил гораздо более сильные морозы по сравнению с центральной частью России, т.к. воздух был сухой.
Был как-то в спб в декабре. По термометру было где-то 0-+2 градуса, я ходил в термобелье и ватных штанах, и все равно через полчаса прогулки становилось капец как холодно.
Друзья: 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
Неоднозначный вопрос. Когда-то давно был удивлен, что Alibaba со своими дикими нагрузками живет на MySQL и не кашляет.
Тут возникает вопрос, так ли плохи "универсальные" решения.
Простите мне мою оплошность, я забыл что на хабре каждый второй — Шелдон Купер*. Впредь, во избежание недоразумений, я все свои шутки буду помечать курсивом и делать сноску** — дабы не вводить в заблуждение писателей, читателей и комментаторов.
*Шутка.
**Шутка встроенная в шутку — одновременно рекурсия и самоирония.
А сколько будет стоить ее создание и поддержка? Как эти цифры соотносятся со стоимостью железа? Был проведен анализ и на его основе принято бизнес-решение?
Предположим что разработка СУБД в целом займет месяц-два работы и потом затраты на поддержку оной будут составлять уже каких-нибудь $15/h (типа часов 16 часов в месяц например). Итого инвестиция окупится через каких-нибудь месяцев 6.
Возможно эта инвестиция сможет убавить издержки и на другие вещи, суппорт серверов, трафик, хранение логов. Возможно специализированное решение позволит существенно снизить задержки, что позитивно скажется на общем UX приложения и пользователи будут более лояльны. Ну то есть масса вещей есть.
Понятно что если вы просто вася пупкин — не надо вам делать свои СУБД. Разве что как хобби.
p.s. я все ж подозреваю что кушать эти разработчики будут чуть меньше.
Можем предложить, что серваки стоят в нашем ДЦ, и кушают 5$ час, а разработчики выкатили mvp за два месяца, а потом сказали, что надо допиливать еще года два и команда нужна человек 6-10, которую надо хантить на особые условия, ибо БД не каждый сделает.
Тогда цифры другие.
Не думаю, что оно продуктивно, представлять сферических коней.
Клево было бы услышать экономическое обоснование от разработчиков. Ну или действительно дело с "фатальным недостатком".
Грубо говоря, даже если мы считаем цены амазона завышенными вдвое, то выходит 300$ в час против не более 25$ в час одного разраба (сервера на ночь не выключаем, потому что это сервера с данными). Такое окупится даже если разработка займет 300/25=12 месяцев.
кушает он только в рабочее время
Я и считал 160 часов в месяц.
и все-таки немного поменьше
Суть была не в том что бы конкретные цифры обсудить, а в простом соотношении и времени окупаемости. cost/benifit анализ. Подставляя свои цифры мы можем прикинуть что и как.
Например Вася пупкин начитался статей о том как люди делают всякие кафки, касандры и прочие кликхаусы, и подумал "а чем я хуже, я ж тоже могу!". И введение кастомного решения у него затратит его времени на $10K а сэкономит он $100 в месяц, окупаемость ~10 лет. Вместо этого инвестировать время можно в другие вещи.
А вот если вы фэйсбук со своими датацентрами, и у вас все на php, то выгодно нанять команду высококвалифицированных C/C++ разработчиков что бы они вам на LLVM JIT компилируемый язык нарисовали, который позволит вам в 2-3 раза уменьшить нагрузки на железо (вот ту миллионы) +, поскольку у вас контроль за языком — позволят ввести новые фичи в язык, которые существенно упростят тот же статический анализ (array shapes, type aliases).
Ну то есть помимо очевидного бенифита в виде сокращения издержек на сервера, мы имеем косвенные бенифиты.
ну и да, реально довольно часто хочется что-то маленькое, специализированное и скучно. А потом уже под это дело можно и бенифиты придумать.
Вспомните такое приложение как маскарад. Там внутри очень даже кастомное решение которое пилилось насколько я помню больше года явно, как хобби. А потом хакатончик, чуть допилить и вот вас уже покупает фэйсбук.
Я конечно все понимаю, но как то очень оптимистично.
специализированная СУБД, под конкретную задачу. Это не база данных общего назначения. Потому да, не вижу ничего страшного в 2-х месяцах.
А тестирование? А затраты на внедрение?
Вы можете внедрять новую систему планомерно, получая профит постепенно и тестируя в реальных условиях. Это существенно упрощает вопрос.
И это ещё не факт что вообще взлетит.
обычно перед тем как решаться на такое уже должен быть некий proof of concept который доказывает эффективность решения.
Разве что они наняли гениев, которые за два месяца написали весь функционал.
Решение после обкатки было выложено в опенсурс как раз что бы уменьшить и эти издержки (хотя сам факт выкатки в опенсурс это тоже дорогое удовольствие).
Как по мне то это очень сложные вопросы
суть вопроса проста — вы должны оценить риски, затраты и профит. Можно проиграть, можно выйграть. Конечно ответы на эти вопросы — это сложно. Но это не настолько сложные вопросы с учетом масштабов.
И да, я забыл рассказать еще об одном аспекте таких решений. Предположим что ваша компания может себе позволить такое удовольствие как написать свою СУБД. Помимо решения каких-то внутренних проблем, это вам даст еще возможность отправлять людей на конференции и повышать престиж компании среди разработчиков. А это в свою очередь будет создавать конкуренцию за рабочее место. И если вам позвонят из компании и скажут "а не хотите ли вы придти на собес" то большинство ответят "конечно хочу".
У многих компаний существует такая практика. Найм людей тоже штука дорогая.
специализированная СУБД, под конкретную задачу.
Людей смущает громкая аббревиатура СУБД, как я понимаю. С тем же успехом можно было назвать это оптимизированным мемкэшем, с прозрачной записью на диск, так?
но вообще — просто поресерчите истории популярных опенсурс продуктов. Подавляющее большинство рождались в недрах каких-то компаний.
Возьмите тот же angular — его пилили в гугле как хобби. А сегодня это один из самых популярных фреймворков. Или react — его так же пилили в facebook годами перед тем как зарелизить. Тот же graphql это так же был внутренний проект.
nginx — писался под рамблер, и стал популярным решением так же далеко не сразу и был намного проще в начале своего пути. Кафка так же пилится с 11-ого года, но из всех щелей она лезет только последние год-два.
ClickHouse так же пилится с 2009-ого года, и на тот момент когда начинали пилить только только появились сырые хадупы и касандры. Потому на тот момент рисков явно было меньше а профита явно было больше.
А есть еще где почитать про структуру VK?
Ещё можно посмотреть доклады (в т.ч. с хайлоада) на YouTube, например www.youtube.com/watch?v=P4HkWuVtsdA
В принципе, ощутимая часть инфраструктуры VK была выложена Павлом Дуровым в open source вместе с документацией.
Можно ссылку?
но это выглядит как заброшенный проект
Заходил как-то на странички знакомых, последние апдейты у многих 5-летней давности, такое ощущение что надоело всем. С Одноклассниками аналогично, когда-то был бум интереса, потом затихло все.
Сам тоже давно не пользуюсь.
Мне тоже кажется, что VK сдает позиции. И вообще, все социалки проиграли безнадежно фейсбуку. Сколько бы я не заходил в VK, он просто не выдает мне ничего интересного из жизни друзей. Может быть у них нет никаких событий, а может быть алгоритм генерации ленты ущербный. Потому что если подписаться на группу, в которой много сообщений в день (такая как Мотомосква), то все лента будет забита сообщениями из Мотомосквы, в которых почти невозможно увидеть случайно затершийся пост от друзей.
При этом в тех же группах с большим количеством подписчиков совершенно невозможно общаться, так как комментарии, например, не группируются по веткам, невозможно понять кто кому когда ответил. В той же Мотомоскве комментарии идут простынями по 100-200 сообщений, в которых никак не понять кто кому отвечает.
В общем, раньше это был бесплатный проигрыватель музыки. Сейчас сложно понять, зачем нужен.
Прошу прощения у сотрудников Контакта, но ведь действительно, сложно понять, зачем продолжать пользоваться вашим сайтом.
Немного закулисья VK