Facebook перевёл (https://logdevice.io/blog/2018/09/12/open-sourcing-announcem...) в разряд отрытых продуктов LogDevice (https://logdevice.io/), распределённую систему хранения последовательно поступающих наборов данных, таких как логи, данные мониторинга, сведения об изменении конфигурации и потоки информации о событиях. Система ориентирована на надёжное и отказоустойчивое хранение логов, обеспечивает сохранение порядка поступления записей и может масштабироваться для обработки миллионов разных логов в одном кластере хранения с интенсивностью поступления данных в несколько гигабайт в секунду. Код написан на языке С++ и опубликован (https://github.com/facebookincubator/LogDevice) под лицензией BSD.LogDevice может адаптироваться для различных видов нагрузки. Например, может использоваться для сохранения потоков событий от особо важных подсистем, гарантируя целостность всей поступающей информации и минимальные задержки на обработку данных, или применяться для принятия больших объёмов данных для контроля тренировки систем машинного обучения. Для обеспечения отказоустойчивости все поступающие данные реплицируются на несколько узлов. Автоматически обрабатываются ситуации выхода узлов из строя и деградирования производительности узлов (данные и нагрузка перераспределяются на другие узлы). Движок локального хранения на узлах основан (https://logdevice.io/docs/Concepts.html) на RocksDB (https://www.opennet.dev/opennews/art.shtml?num=38499) и оптимизирован как для применения жёстких дисков, так и SSD-накопителей.
В хранилище данные поступают в виде непрерывного потока записей. Запись неделима и является минимальным объектом адресации в хранилище.
Каждая запись снабжена своим уникальным идентификатором последовательности (LSN - Log Sequence Number). Осуществляющее передачу логов приложение получает информацию о присвоенном LSN после подтверждения успешной записи данных в хранилище. При чтении приложению для обработки могут возвращаться сразу несколько записей, но адресация производится только на основе LSN, т.е. хранилище может вернуть N записей начиная с указанного LSN.
Хранилище работает в режиме пополнения, который допускает только добавление новых данных. Изменение и удаление не поддерживается. Хранилище рассчитано на неограниченное время хранения записей, но предусмотрена и возможность чистки устаревших данных. Для проведения чистки устаревших записей предлагается использовать урезание лога, при котором удаляются все старые данные путём отсечения части лога. Урезание логов может производиться как по команде администратора, так и автоматически через определённые промежутки времени или при потреблении заданного объёма дискового пространства.Для управления предлагается API и утилита командной строки ldshell (https://logdevice.io/docs/LDShell.html), поддерживающая интерфейс LDQuery (https://logdevice.io/docs/LDQuery.html) (команда query) для формирования запросов данных и оценки состояния кластера при помощи конструкций в стиле SQL.
URL: https://logdevice.io/blog/2018/09/12/open-sourcing-announcem...
Новость: https://www.opennet.dev/opennews/art.shtml?num=49264
Почему на C++ написано а не на Python/Django?
еще на электроне или пыхе предложи.
потому что мы попытались, как обычно, на php, но получалось как-то не очень.а на пихоне это вам в гугл.
что-то гугл уже не очень то на питоне пишет.... Может лучше на php?
Ваша информация устарела. Теперь в Google используют Golang.
Но не все и не везде, но почти ...
> с интенсивностью поступления данных в несколько гигабайт в секунду
сейчас тебе расскажут, что в пихоне с инпутом/оутпутом все равно работает сишный код. И вообще, на пихоне работало бы на 146% быстрее, чем на плюсах
Какой хороший вброс! Он мне по душе!
Это выброс. Очевидно же.
Лучше на asm
Не лучше, тут лучше на Си. Я в свое время делал турбореактивный обработчик поступающих данных на Си, поэтому знаю что и как нужно делать.
Ну и как у них решение по сравнению с вашим? Выше ерешние в откуытом доступе?
>Я в свое время делал турбореактивный обработчикНа Турбо-Си.
Борланд крут!
в трубу этот си )
Потому что продакшн-решение для хайлоада?
их разьве не на пихоне обычно делают? ;-)(а, простите, на пихоне пишут файловые системы)
Для себя, для домашнего применения (соответственно, небольшие нагрузки) - без проблем хоть питон, хоть бейсик, если ты о Zero и подобных. Единственный критерий - удобство того, кто пишет (и сам же потом будет пользоваться).И было бы неплохо, чтобы с энтерпрайзами такие штуки (фактически - слегка переросшие скрипты домашней автоматизации, которыми решили поделиться с другими людьми) не путали - требования совсем другие.
а время для себя у тебя бесплатное, да?мне вот как раз для себя хочется 10g свитч с fcoe - потому что себя жалко (и провода короткие и дорогие).
А менеджеры - "еще подождут".
Ну вот потому и питоны всякие:а) потому что пишешь на том, что и так знаешь, а не изучаешь "идеальный" язык
б) пишешь ровно так, как тебе надо - без излишней сложности там, где она не нужна. В том числе не пытаясь экономить там, где нет (у тебя!) узких мест
> для домашнего применения ... Единственный критерий - удобство того, кто пишетИ наручниками того, кто такое пишет и такими критериями руководствуется, дома к батарее приковать, чтобы с таким подходом к делу из дома не мог выйти.
>> для домашнего применения ... Единственный критерий - удобство того, кто пишет
> И наручниками того, кто такое пишет и такими критериями руководствуется, дома к
> батарее приковать, чтобы с таким подходом к делу из дома не мог выйти.А тебе плеточку выдать, чтобы мог объяснить всю глубину заблуждения и замотивировать сделать правильно?
Кстати, надеюсь, бутерброт колбасой на язык кладешь?
> бутербротнадеюсь что это были твои последние потуги что-то пытаться возразить более интеллектуальным лицам
> И наручниками того … к батарее приковать
> потуги что-то пытаться возразить более интеллектуальным лицамИтнеллеХт и аргументационная мощща прям таки и прет!
а зачем приковывать - он и так никуда не выйдет, "счас-счас-счас, оно досинхронизирует..."
Пример. Есть тысяча файлов, по 20 мегабайт каждый. Будет там разница в скорости синхронизации между питоном и сями да хоть и на сотне мегабит?
> Пример. Есть тысяча файлов, по 20 мегабайт каждый. Будет там разница в
> скорости синхронизации между питоном и сями да хоть и на сотне мегабит?Будет! Мы, анонимы точно знаем, как офигительно быстро FUSE (ведь оно на сях, че там тормозить может-то?).
Но вам не покажем, потому что на питоне делать не труЪ (это мы слышали сто раз от других 3,5 анонимов и прилежно повторили, а значит это правда!), а на сях мы не умеем^W хотим, ведь нам не нужно!
поищите на досуге ранние тесты производительности ntfs-3g. Они, по-моему, сохранились уже только в виде копипасты, но их много накопипастили, гугль найдет.fuse там дала прогадиться так, что Линус и компания в панике перерыли код ext2/3 (устранив таки приличное количество узких мест) - конечно не потому, что их переплюнула, но потому, что на некоторых операциях умудрилась дать тот же порядок величины - чего быть было не должно никак и никогда (если бы ext3 не писалась методом латания дыр)
А автор так, с политкорректной миной "...вообще-то...ну...я еще дебаг у себя не отключил..."
(замеров с отключенным так никто и не рискнул проводить, но вот вам свеженькое, хотя и не линукс:
# tar cf - * | team 16m | tar -C /mnt/c/microsd -xvf -
...
8632910 kilobytes, 342 seconds
- уперлось во вполне себе in-kernel mirror на том конце где c - при том что это запись/создание мелких файликов, оно у ntfs медленное by design, а тут еще и context-switching, с модным kpti, поди ;-)к сожалению, победа так и осталась единственной. fuse-exfat непередаваемо тормозное и недоделанное (не понимает кодировок, отличных от utf8) дерьмо, спасибо самсуню за работающий .ko. zfs-fuse (заметим, там только posix layer fs, нижний уровень был в ядре) не только тормозила, а еще и падала без конца. fuse-dav однотредовая. Просто некоторые и на си пишут какашку, да еще и не хотят ее отлаживать "это ж fuse, оно всегда тормозит".
> поищите на досуге ранние тесты производительности ntfs-3g. Они, по-моему, сохранились уже только в виде копипасты, но их много накопипастили, гугль найдет.https://web.archive.org/web/20080516235826/http://www.csamue.../
> fuse там дала прогадиться так, что Линус и компания в панике перерыли
> код ext2/3 (устранив таки приличное количество узких мест) - конечно неБерем шаблонный хелловрот для фузе, тупо отдающий файл c tmpfs.
Можно даже нагуглить "со всеми оптимизациями".
Сравниваем с tmpfs, чешем репу.
То, что оно на харде вполне может быть сопоставимо с нативом, никто не спорит, но попытка прокачивать большие файлы будет обломна (пару лет назад пытался свелосипедить мульти-медиа ФС на базе фузе - прилетела птица обломинго).
> 8632910 kilobytes, 342 seconds
> - уперлось во вполне себе in-kernel mirror на том конце где c
> - при том что это запись/создание мелких файликов, оно у ntfs
> медленное by design, а тут еще и context-switching, с модным kpti, поди ;-); 8632910/342/1024
~24.65080752010233918129
25 MB/s - очешуительная скорость, ага.Особенно когда распаковываешь с NTFS-изошки на SSD в натив (тоже SSD). Оно, кстати, при монтировании без max_read еще и после пары десятков тысяч файлов зависнуть норовит.
> https://web.archive.org/web/20080516235826/http://www.csamue...не, это не то, это когда уже успели линуксное ядро пооптимизировать. Ищите ~2004й, где сравнивали ext3 vs ntfs, до оптимизаций. Я, увы, хз как искать, не потрудился сохранить.
> Сравниваем с tmpfs, чешем репу.
в смысле, на тему нахрена мы это ненужное ненужно сделали и что делать с этим результатом?
> То, что оно на харде вполне может быть сопоставимо с нативом, никто не спорит
да? То есть то что все эти танцы с бубном вокруг vfs да еще и двойной контекст-свитчинг на каждой операции остаются сопоставимы с native, а не оказываются раз в десять тормознее, это, типа, нормально, так и должно быть?
Нууу, ооок... Может тогда и на пихоне у ребят выйдет неплохо.> 25 MB/s - очешуительная скорость, ага.
оно больше не шмагло - уперлось в ядре. Или в возможности самой флэшки, что тоже вероятно. Нет, destination-то не ssd а собственно флэшка. source умел от 18 до 40 (поскольку странен)
Хотя опять же - не самая быстрая по исходной задумке fs вообще, не самый хороший для нее usepattern в частности, и еще и fuse, причем в неродной для той системе через еще один местный костылик. Если бы все было как надо, оно бы уперлось в user cpu. Вот с davfs2 - у меня все как надо, ага. Причем в ядре без антипатчей производительности.Если бы я не знал всего что выше - я бы считал что "нуу, fuse, dav, оно ж не может в принципе нормально работать".
оно и впрямь не должно, но вот exfat бы хотелось, ан, теми же руками и из того же сырья слеплено :-(
>> Сравниваем с tmpfs, чешем репу.
> в смысле, на тему нахрена мы это ненужное ненужно сделали и что
> делать с этим результатом?В смысле, на тему разницы и "порядков величин", когда оно не упирается в IO ноутбучного диска.
>> То, что оно на харде вполне может быть сопоставимо с нативом, никто не спорит
> да? То есть то что все эти танцы с бубном вокруг vfs
> да еще и двойной контекст-свитчинг на каждой операции остаются сопоставимы с
> native, а не оказываются раз в десять тормознее, это, типа, нормально,Да? Оно уже не жрет на это дело в десять раз больше CPU, чтобы дать "дать тот же порядок величины"? Ну оок.
>> 25 MB/s - очешуительная скорость, ага.
> оно больше не шмагло - уперлось в ядре.
> ...
> ource умел от 18 до 40 (поскольку странен)
> ...
> fuse, причем в неродной для той системе через еще один местный
> костылик. Если бы все было как надо, оно бы уперлось в
> user cpu. Вот с davfs2 - у меня все как надо,
> ага. Причем в ядре без антипатчей производительности.Издеваетесь?
А ты не охренел?Я как-то всегда считал, что если человек что-то сделал для себя и поделился с другими - то ему либо "спасибо" говорят, если пригодилось, либо игнорируют, если не нужно. Ну можно ещё предложить что-то изменить, с пониманием того, что не факт, что автор это дело примет, и это его право. А тут кто-то решил, что автор ему обязан?
не, ну еще поржать могут. Не всегда по-дружески.
В случае zero как раз этот вариант.а мордокнигу придется игнорировать - не потому что плохо, а потому что неудачная для меньших чем мордокнига целей конструкция.
В случае zero у кого-то подгорело, что обидели webdav. Ну и аллергия на питон обострилась, без попыток понять, годится ли он в конретном случае и какие задачи им пытаются решать.
Потому что в Facebook разработчики, тьфу-тьфу, не больны на всю девопсину.
Фишка в том что написанный на C++ код можно забиндить к любому другому языку. Чего не скажешь про питон (который сам активно использует C в своих библиотеках).
C/C++ по факту еще и самый интероперабельный язык, на уровне прямых библиотечных вызовов (не модных вебсервисов для любой мелочи).
Perl наше все
> Почему на C++ написано а не на Python/Django?Потому что:
> с интенсивностью поступления данных в несколько гигабайт в секундуА попробуй так на питоне данные пожевать, узнаешь много нового как там и что не тормозит :)
Семантику exect once поддерживает?
exect once не поддерживает точно
а фильтровать логи при просмотре как они предлагают?
> а фильтровать логи при просмотре как они предлагают?Ты где-то видел в новости строки про чтение или просмотр ? Русским же по белому написано "сохранение" и "добавление".
Чтение ненужно.
> Чтение ненужно.Могу предложить новое хранилище
/dev/null
он у вас не шардится, не параллелится, и производительность под вопросом.
> он у вас не шардится, не параллелится, и производительность под вопросом.Как не параллелится? Запустил копирование туда всех файлов на 10 компьютерах, работают все 10 параллельно.
А бюджет IT отдела под что выбивать? Как объяснить что новый датацентр ежемесячно не нужен?
там что даже индексов нету?
Нету. Оно для хранения и потокового анализа (разобрал, оценил, по необходимости выполнил действия, дропнул). При надобности можно отмотать по LSN и повторить разбор.
Неудаляемые значит... А как же GDPR? :)
все норм, там не сказано что мы обязаны это удалять - сказано что мы должны вас об этом заранее предупредить. Вы, конечно же, получали наше обновленное TOS (и, кстати, согласились с ним, о чем в logdevice есть запись)? Ну вот, на странице 68 внизу...
> все норм, там не сказано что мы обязаны это удалятьявно сказано. По запросу должно быть всё удалено, причём имеют право запросить подтверждение того, что удалено.
Так вам подтвердят, что удалили. Могут даже диплом с большой собачьей медалью выдать. Только как вы проверите? В дата-центр поедете?
эммм, мы конечно рады что вы так думаете, но один ирландский парнишка оказался поумнее :-(
> Только как вы проверите?Для этого есть правохранительный органы. Если лицо, которое обратилось, имеет сомнения, то именно они попросят продемонстрировать, как это было сделано. На самом то деле, это не смешно, если у вас бизнес в Евросоюзе.
Продемонстрируют, что хранят только обезличенные логи, вот эти 64 байта - это sha-512 от рандома.(На самом деле, это зашифрованные AES-ом user id и ip, но как докажешь?)
Там же реализовано так же как в гугль аналитике, 90 дней и все логи на помойку. Обезличенные логи можно годами хранить для дата-майнинга
Единственная польза, которую данная сосалка рпиносит человечеству - открытые коды. Мне понравился их проект ООМа, который бы в энтерпрайз завести.....
а можно вместо этого саму идею oom в ее линуксной реализации вынести?