У меня нет для вас готовых цифр и красивых графиков до\после, к сожалению.
Мы используем Go очень давно. На ранних этапах мы постоянно боролись с GC. Даже делали доклад на тему оптимизации Go на meetup, который проходил в нашем офисе. Но с каждой новой версией Go становится лучше и более приспособленным для высоких нагрузок и сервисов, которые используют много памяти.
Если говорить про Си VS Go в плане производительности, то Go, конечно, проигрывает. Но Go на порядки удобнее для программирования. Делать многопоточную систему на Go — удовольствие, а на Си — морока. Если посмотреть чуть шире, то за счет этого удобства вы сможете написать распределенную систему на Go, которая будет работать лучше, чем система на Си. Не за счет банальной скорости, а за счет того что к моменту как система на Go уже будет вовсю работать и работать отлично, на Си вы будете искать ошибки в многопоточном коде.
Нет, не рассматривали. У нас в данной задаче нет "зоопарка" разных систем, которые пишут логи. Собираются логи только наших самописных демонов, формат логов которых уже унифицирован.
Т.е., как мне кажется, для данной конкретной задачи fluentd просто не нужен.
Верно. Один индекс = 1 шард + 1 реплика.
Такое число мы выбрали сознательно, основываясь на документации, нашей задаче и некоторым статьям с рекомендациями в интернете.
Один шард — это один Lucene индекс, а поиск по индексу должен затронуть все шарды. Т.е. если два разных шарда находятся на двух разных нодах, поиск затронет обе ноды. Т.к. у нас один индекс на день и он не супер-пупер большой, то мы посчитали правильным ускорить поиск за счет использования одного шарда.
По вашему тону я могу судить что вы считаете это неправильным?
Да, Юра тоже прав. Если взять один из наших самых нагруженных сервисов, то суммарно на трех машинах он занимает в памяти около 1,3 TiB. Тщательное управление памятью в этом случае очень важно.
Почему у нас больше всего демонов на Си?
Вопрос многогранный.
Во-первых, потому что мы хорошо знаем и любим Си.
Во-вторых, Badoo существует давно и 10 лет назад было такого большого выбора вкусных языков, как Go или Rust.
В третьих, у нас действительно очень высокая нагрузка. Мы, к примеру, в некоторых демонах используем JIT компиляцию для конвертации поискового запроса по битовому массиву в sse/avx/avx2 машинный код.
Сейчас же, если нам не требуется супер высокой производительности, мы предпочитаем Go.
Штуки в сторону, такие ситуации у нас обходятся таким образом, что треугольники пересекаются, накладываются друг на друга. Т.е. пользователи в какой-то области будут дублироваться в накладывающихся треугольниках.
Мы в Badoo для конфигурационных файлов демонов используем как раз json. Похачили сишную json либу и теперь можем делать комментарии и оставлять последнюю запятую в списках.
Мы используем Go очень давно. На ранних этапах мы постоянно боролись с GC. Даже делали доклад на тему оптимизации Go на meetup, который проходил в нашем офисе. Но с каждой новой версией Go становится лучше и более приспособленным для высоких нагрузок и сервисов, которые используют много памяти.
Если говорить про Си VS Go в плане производительности, то Go, конечно, проигрывает. Но Go на порядки удобнее для программирования. Делать многопоточную систему на Go — удовольствие, а на Си — морока. Если посмотреть чуть шире, то за счет этого удобства вы сможете написать распределенную систему на Go, которая будет работать лучше, чем система на Си. Не за счет банальной скорости, а за счет того что к моменту как система на Go уже будет вовсю работать и работать отлично, на Си вы будете искать ошибки в многопоточном коде.
Т.е., как мне кажется, для данной конкретной задачи fluentd просто не нужен.
Такое число мы выбрали сознательно, основываясь на документации, нашей задаче и некоторым статьям с рекомендациями в интернете.
Один шард — это один Lucene индекс, а поиск по индексу должен затронуть все шарды. Т.е. если два разных шарда находятся на двух разных нодах, поиск затронет обе ноды. Т.к. у нас один индекс на день и он не супер-пупер большой, то мы посчитали правильным ускорить поиск за счет использования одного шарда.
По вашему тону я могу судить что вы считаете это неправильным?
Вопрос многогранный.
Во-первых, потому что мы хорошо знаем и любим Си.
Во-вторых, Badoo существует давно и 10 лет назад было такого большого выбора вкусных языков, как Go или Rust.
В третьих, у нас действительно очень высокая нагрузка. Мы, к примеру, в некоторых демонах используем JIT компиляцию для конвертации поискового запроса по битовому массиву в sse/avx/avx2 машинный код.
Сейчас же, если нам не требуется супер высокой производительности, мы предпочитаем Go.
Но разве можно отказаться от такого революционного открытия, как гексасфера? Можно ее просто сделать гуще! Равномерно гуще! :-)