Компания PayPal открыла исходные тексты отказоустойчивой СУБД JunoDB, манипулирующей данными в формате ключ-значение. Система изначально спроектирована с оглядкой на высокую безопасность, горизонтальную масштабируемость, отказоустойчивость и способность обрабатывать сотни тысяч одновременных соединений с предсказуемыми задержками. В PayPal практически все сервисы, от входа пользователей до обработки финансовых транзакций, завязаны на JunoDB. Код проекта написан на языке Go (клиентская библиотека на Java) и распространяется под лицензией Apache 2.0. При дальнейшей разработке будут приниматься исправления, улучшения и изменения от сообщества...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59169
350 миллиардов? какая-то брехня.
Почему брехня. Это в день.350000000000 / 86400 = ~4 миллиона запросов в секунду, если учесть что это колонковое хранилище, не так уж и много, просто здоровый кластер и шардинг по группе юзеров в итоге, когда у тебя все данные полностью шардятся, достижимо почти на чём угодно.
По производительности параметры ж в материале указаны:
3 узла с конскими параметрами: 32 CPU Intel Xeon 2.30GHz, 214G ОЗУ и 450G хранилище на базе SSD
И всего 15000 запросов в секунду. Это миллиард в день. Чтобы это смасштабировать на 350 миллиардов - надо полторы тысячи узлов минимум, если у тебя всё удачно шардится. Не много, но и не мало.
> надо полторы тысячи узлов минимуми тут ВНЕЗАПНО выясняется что синхронизация протестированная на трех - немножко не очень работает на полутора тысячах.
В общем был я лучшего мнения о пэйпалке. Впрочем, подозреваю, это чудо в перьях существует гораздо меньше чем пэйпэл, тот с которым я когда-то имел дело - использовал что-то совсем другое.
синхронизация ЧЕГО?
данные в базах никуда не синхронизируются кроме как на рядом стоящую ноду...для отказоустойчивости... алллоо..меня слышно?
синхронизируется там только etcd. Но это отдельная пестдня...
Полторы тысячи нужно для гарантировано минимального отклика в 2.5мс читай новость внимательней
Читаю - написано что эти 2.5ms (интересно, чем и в какой точке меряли-то?) - это та самая экспериментальная установка аж из целых ТРЕХ серверов.Про характеристики той что полторы тысячи - ничего нет кроме запросов в секунду.
А теперь пингани свой ближайший локалхост и посмотри 95% время ответа на icmp (не tcp! не userland! на пустой сети!). И еще разок взгляни на схему с кучей проксей поверх проксей. И еще что-то там про геораспределенность, явно не все в один мегасвичт воткнуто.
"по-моему, где-то нас нае...ли"
Да, а потом кто-то эти значения натянул на 350млрд. Зачем? Не факт, что на проде палки такой же отклик, зачем им это.
Пинганул локалхост:
0.020 msих 2,5ms - на два порядка больше.
"Ближайший локалост" ты наверное имеешь в виду в локальной сети? которая 100Мб ?
Один персонаж из фильма на такие эксприменты говорил так:
"Я тут это... экскримент хочу сделать" (с)а у них а у них там хосты или виртуаки, или 10-20-40Gb сеть... так что пинг будет почти такой как у локалхоста.. ну можент чуть похуже...
Хз, сколько там нужно для 350 млрд, в теории-то вообще 350, потому что 3 - это 1 млрд, но по факту я натянул с потолка полторы тысячи, потому что 100% и шардинг и собственно интерлоки хромать будут.
Размещение данных в RAM - вот и весь секрет.
Ну да, рам в половину хренилища. Хотя рокздыбыбл половину сожрёт на внутренние операции.
Нужно ж понимать еще одну простую вещь - я в те годы когда не жил в Одичалии за Стеной пользовался палкой, да - но я ей пользовался раз в два-три месяца. Полагаю это вполне типичный use-pattern, и 90 или больше процентов этой базы на самом деле нахрен в памяти не сдались. Остальное - какие-нибудь ларьки по продаже чехлов к телефонам, которые долбят своими копеечными заказами с диким рейтом.А если прикинуть как часто (нет) нужны какие-нибудь исторические транзакции - то как бы не 99.9% ненужно получается.
Возможно, конечно, у них все же транзакции хранятся где-то отдельно и в более подобающем формате, но это мягко говоря не доказано.
Да а зачем транзакцию отдельно то хранить? Есть ID транзакции, в ней есть ID юзера как value, в ней есть прочие ID связок как value, поиск делается по любому индексированному ID, далее выхватывается всё, что надо.
так искать-то я буду не id транзакции. Я буду искать либо по кому (не id а value!) ушло, либо когда. чтобы мне показать список - нужно искать по мне и сортировать по дате (value).
С биллингом то же самое - даты, имена, что угодно но не id.Про интегральную целостность тоже непонятно в таком раскладе - тебе надо мильен ключей и значений на каждую операцию сохранять, где там гарантии и есть ли они вообще, неясно, а денежки - материя тонкая, требуют аккуратного счета.
Скорее всего там сохраняется блоб, и парсится уже в приложении а не базой. Медленно, неудобно, неэффективно, зато масштабируется по числу серверов приложения.
По value находим id кого. По id кого находим собственно id транзакций с этим id кого. По id транзакций выбираем даты. Сортируем. Выгребаем по нужным id всё остальное. KV - оно такое.
Ну да, потом удивляемся откуда взялись 300 миллионов запросов. Вот оттуда. KV такое KV. И искать в нем id по value - неожиданно (нет) очень дорогая операция.
> я ей пользовался раз в два-три месяца
> Полагаю это вполне типичный use-patternУ вас поховый солипсизм. И пэйпал, конечно же, нагло врёт про 350 миллиардов, специально чтобы опеннетовских экспертов позлить. Ох, уж этот пейпал, такие-то гадюки!
Причём тут RAM? Там нет такого количества запросо. Разве что что сам сервис ещё делает 10к запросов к внутренним сервисам при любом запросе извне.
Маск цену себе набивает... Продаваться хочет...
в 214G ОЗУ ?
Только - вот новость-то - абсолютно все сколь-либо тиражные СУБД размещают оперативные данные ИСКЛЮЧИТЕЛЬНО в РАМе. И работают ТОЛЬКО с РАМой.
Опять не sql и не на Си, что же скажут местные иксперты?
Go для прикладных задач всегда топ. Он быстрый, безопасно работает с памятью, простой.
Там RocksDB на подложке, на игого только обвязка.
Очень вырожденный случай, для узкоспецифичных применений.
И? Все правильно сделали писать всё на спп это в 10 раз дольше и в 100 раз дороже. Go топчик, а ты хейтер.
Для данного вырожденного случая (запросы наверняка банальные get value by key и store value by key, без сложных выборок) - ну, норм.
Я как-то сомневаюсь что случай вырожден, а не навязан убогостью решения.Так как в общем-то любую таблицу можно развернуть в пачку key-value, но все эти миллиарды запросов - они ровно потому, что там где в нормальной базе был бы один - тут их приходится сделать последовательно десять.
А потом еще парсить сложный формат этого самого value, выковыривая из него требуемые куски.
Ну, там мелкие финансовые транзакции. Здесь снять, туда записать. Сложные выборки разве что для статистики.
Ну да. Вот у тебя транзакция - от кого, кому, когда, сколько - это минимум. Еще там где-то конкретика откуда взялись деньги и куда потом попали - карта, счет, тип (операции частных лиц отличаются у палки от коммерческих)
Ну и как мы будем это в key-value пихать, с учетом что искать потом будут по любому из этих полей? Причем в самую последнюю очередь - по уникальному id.
Ну дык да, всё лепится на общий ID, дальше поиски по нужному value от этого ID, и по ID выхватывается всё остальное.
Учитывая что на подложке rocksdb - можно было и на цыпыпы, просто видимо игогошники дешевле обошлись.
Вы б глянули, почем нынче игогошники
Ты бы уже начал думать в разрезе эффективности, а не цены. 1 го программист пишет столько же сколько пишут 10 сиплюплюсников за те же деньги.
Гопники вынуждены писать длинные макаронные портянки, накапливая техдолг и баги. Примерно то на то и получается.
Да эти знаменитые С++ макаронные портянки это что-то с чем-то. На го все коротко ясно быстро и элегантно. На го в 10 раз меньше затрат.
> 1 го программист пишет столько же сколько пишут 10 сиплюплюсников за те же деньгиОдин гошник работает за десятерых вдесятеро более дешёвых сишников ?
Но у разработчиков редко зп растёт на порядок при прочих равных
Т.е получается примерно сравнение одного среднего/почти-ведущего программиста с десятком стажёров
Но в таком случае, скорее всего, один средний проггер в любом случае полезного кода напишет больше тупо потому что стажёрам многое придётся переписывать
> Ты бы уже начал думать в разрезе эффективности, а не цены.Давно уже, и не только думаю :) Народ вы читаете перед тем как пишите или полностью - телепатия.
>1 го программист пишет столько же сколько пишут 10 сиплюплюсников за те же деньги.Понятно, - не в теме... программист на Го дороже, а не дешевле плюсовика
Яблоки против апельсинов? У обоих языков разные области применения и каждый из них хорош в своей области. Конечный результат оценивается не в количестве настроганного кода, а в качестве при быстроте реализации. Можно конечно написать на Го операционныю систему, но лучше юзать right tool for a job, также как тупо юзать плюсы там, где это значительно быстрей и с меньшими ошибками изпользовать эффективно Го
> Вы б глянули, почем нынче игогошникиВесь бангалор к вашим услугам, недорого. Плюсовики дороже, у бангалорцев плюсы туго идут.
> Весь бангалор к вашим услугам, недорого.Недорого? Или информация 30 летней давности?
Система изначально спроектирована с косым взглядом на высокую безопасность, горизонтальную масштабируемость, отказоустойчивость.
Как будто кто-то хорошо прошел собес по проектированию архитектуры систем.
> Код проекта написан на языке Go (клиентская библиотека на Java)Дальше в общем можно и не читать.
А что им надо было всё писать на древнежабе потому что все клиенты использую древнежабу?
Ну ежа с ужом - всегда так себе затея. И да, на подложке RocksDB, т.е. на гошечке там тупо микронная обвязка, можно было и нет.
Надо было писать на Malbolge
Скажи спасибо, что не на COBOL. Все равно выглядит как "нате вам боже что нам негоже".
На самом деле это: «Чем богаты тем и рады»
вот мне тоже кажется, что свой велосипед выложили в связи с переходом на какую то мейнстримную базу, чтоб бабло не тратить на поддержку
Э... ну и назови мейнстримную базу подходящую под описанные параметры?
Ну те что про их прод а не экспериментальную схему - известно число запросов в секунду, нужна избыточность и геораспредленность. Предположим даже что нормальный sql сократил бы количество запросов раз в десять. Что крайне маловероятно (не то что сократил бы, а что они могут заменить эту свою поделку на sql не взорвав весь пэйпэл нюком и не построив заново с нуля) - т.е. речь может идти только о no-sql базах. Выбор сводится к поделкам апача... так себе мейнстрим и поддержка.
Ну, для начала, они читерят с баллансировщиком нагрузки, с такими исходными можно обрабатывать теоретически любую нагрузку на распределенные (втч территориально) сервера даже классических sql БД типа Оракла, Постгреса или ДБ2. Да, придется решать вопрос с репликацией, но это возможно.
Но в том то весть прикол, что они используют архитектуру ключ-значение, т.е это как раз NO-sql,
скорее всего они решили запользовать какую ни будь редиску, кассандру, могну или вообще кликхауз :)
Выбросив го-жаба-свой велосипед на мороз, они выкинут вместе с ним отдел программистов и оставят только девляпсов. Кроме того база на Ц может оказаться сильно менее требовательна к оперативе и вычислительным ресурсам, можно будет еще и на серваках поэкономить.
> Да, придется решать вопрос с репликацией, но это возможно.Всего-то какой-то репликацией. Подумаешь, мелочь. Да любой опеннетчик её только так, походцем, одной левой, не отрываясь от комментирования на любимом ресурсе.
>cервера даже классических sql БД типа Оракла, Постгреса или ДБ2.Да, придется решать вопрос с репликацией, но это возможно.Хрен оно у тебя будет работать. ОТ той твоей связки они наверняка уже когда-то убежали свой
мда... специалисты, которых мы заслужили (это про тебя, а не про тех, кто проект и библиотеку писАл)
> с предсказуемыми задержками.
> Код проекта написан на языке Goсразу на gc заложились
Похоже на ceph, только с намного большим количеством посредников.
Это похоже на Apache Ignite только сделанный не там.
Очевидно, что они обновили платформу, а старье выкинули разлагатся в опенсорс. В лучше случае получится еще один зомби Apache Juno.
Да, похоже на phaseout, вот и выкинули.
Более интересно даже - что на замену...
Что-то столь же ужасное - потому что вряд ли они могут себе позволить переделать структуры данных и весь фронт/мидлварь.
А, на фронте там вообще REST скорее всего какой-нибудь, или SOAP, или whatever the fsck goes.
Только мидлварь переделывать, если такое же KV - возможно несущественно.
Ну я и говорю - только если что-то такое же. А зачем им такое же если у них уже есть одно?Что кто-то за них возьмется поддерживать - не верю, опять же с учетом кто и какие делает штуки подобного рода.
А опеннет-экспертам не так просто угодить!Если корпорация выложит старый проект -- "старье выкинули разлагатся в опенсорс".
Если корпорация выложит действующий проект -- "решили воспользоваться бесплатной рабсилой".
Ну а если частное лицо выложит что угодно, то это просто "нинужна!"
Ну какие проекты, такие и отзывы. Ты ведь конечно можешь назвать хоть один действительно хороший проект выложенный в опенсорс за последние лет пять?Хотя бы не вызывающий первых реакций вида "что это за х-ня?!", "кому оно на.. надо?!" и "а еще уродливее просто невозможно или не смогли?"
Я - боюсь что нет.
За десять - буквально по пальцам одной руки пересчитать и то с трудом.
> Ну какие проекты, такие и отзывы. Ты ведь конечно можешь назвать хоть
> один действительно хороший проект выложенный в опенсорс за последние лет пять?
> Хотя бы не вызывающий первых реакций вида "что это за х-ня?!", "кому
> оно на.. надо?!" и "а еще уродливее просто невозможно или не
> смогли?"
> Я - боюсь что нет.
> За десять - буквально по пальцам одной руки пересчитать и то с
> трудом.Действительно, так навскидку вспомнить что-то реально хорошее трудно. Но всё таки, когда выкладывают какой-нибудь проект, обычно сразу находятся энтузиасты, которые начинают коммитить, форкать и т. п. Значит оно всё же кому-то нужно. И вообще, открытое ПО -- это всегда лучше, чем закрытое.
Сколько еще таких чемоданов без ручки в недрах корпораций?
Интересно, есть вообще такие корпы, которые с самого начала имеют четкую позицию не разрабатывать за свой счет всякую прикольную фигню, вместо этого нанимать тех, кто умеет готовить опенсорсные решения?
Нету таких. Потому что тех кто умеет готовить решения на такие нагрузки - вообще в природе нет. Они растут вместе с компанией, или переходят из похожей где выросли - и других вариантов практически не бывает. А дальше делают методом проб и ошибок, иногда очень дорогостоящих, иногда очень такое вот странное но как-то подкостылено и подперто и в их специальном случае - работает.А опенcocники как всегда - cocyт-с. Их удел - локалхосты.
я тебя умоляю. ничего там не растёт вместе с компанией, разве что костыли. и пилят своё исключительно из-за незнания что происходит вокруг
ты-то уже десять пэйпалов перерос? Ты-то знаешь что происходит вокруг и в любую секунду готов им настроить опенсорсное нен.. хранилище хотя бы даже KV на подобные нагрузки - и можешь это подтвердить прошлыми успехами?Только почему же тогда ты работаешь в россиянском подвале с десятком ржавых локалхостов?
Вагон и тележка.
Потому что нужно tailored решение, а не коммунальный шлак - не важно опенсорс или коммерсовый, который фиг под конкретную задачу допилишь.
Чем их задачи отличались от каких-либо других? Ничем. Если компания не тянет подстроить существующие решения, свое решение превратится в неподдерживаемый хлам с вероятностью близкой к единице.
Ну так они и подстроили - взяли RocksDB, налепили tailored обвязки.
>tailored обвязкикостыли
вопрос правообладания и обязательствВдобавок, многие проекты весьма долго тянутся
И начинается всё с того, что взяли наиболее простое, доступное и логичное на тот момент решение, потом под небольшое изменение потребностей под себя доработали, потом ещё
Потом - уже и переезд на более жирный но опенсорс уже не выглядит простым ибо много чего нет или работает не так
И вот, чёрти какое решение, изначально на такое вообще не рассчитанное и подпираемое неведомой горой костылей, скопившихся за годы, тянут до последнего. Нередко заменяя с огромным блоком другого связанного барахла, долго к этому готовясь.А потом - выкидывают это барахло. Только если раньше оно уходило куда-то в архивы или продавалось за гроши, то теперь стало модно выкидывать в опенсорс.
Интересно только, спишут ли они расходы на эту систему как расходы на поддержку опенсорса, каковым то барахло в итоге и стало
1. Выкладываем в OpenSource.
2. Привлекаем заинтересованных разработчиков к проекту.
3. Сокращаем штатных разработчиков.
4. Отчитываемся о сокращении расходов перед инвесторами.
5. Profit.
1. Выкладываем в OpenSource.
2. Получаем набег орды халявщиков с претензиями.
3. Убеждаемся, что пилить вместе с нами никто не намерен.
4. Делим на две ветки - для себя любимых и для всяких.
5. Получаем тонны фекалий и несколько изначально дохлых форков.
6. Окончательно забиваем на открытую ветку.
7. Решаем что такие эксперименты не стоят затраченного времени, и больше ничего не выкладываем в опопенсорс
1. <Company_name> выкладывает в OpenSource
2. Набегают хомячки
3. Собираем налоги, тыкая в README
4. Profit
>манипулирующей данными в формате ключ-значениеGNU dbm?
Berkeley DBSQLite Же !!! Форк, чтоб без хранимых процедур.
Задержки в 2.5 и 16...задержки чего?
Сложности перевода. Посмотрите картинку. там написано как правильно называется упомянутый параметр.
Это то, из-за чего PP такой тормозной?
Это из-за нее пейпал тормозил как скотина и виснул?
> JunoDBЖдем MiddleDB и SeniorDB... Кхм, за деньги, конечно.
MiddloDB и SenioroDB.
MidoDB / SenoDB
Так любимая линуксоидами фрагментация, когда идеи опенсорса распыляются, а выживают только проекты под покровительством спонсоров, которые девочку и танцуют.
> Так любимая линуксоидами фрагментация, когда идеи опенсорса распыляются, а выживают только
> проекты под покровительством спонсоров, которые девочку и танцуют.Смотри, анончик, как бы твою девочку кто не танцевал, пока ты тут жиденько накидываешь.
Не заработал он еще на девочку.