Я не стал выливать эту боль в посте. Проблема состоит в том, что недостатки раскрываются с ростом базы данных, в процессе эксплуатации. Остается либо лупоглазить в код либо читать описания/отзывы и прикидывать во что это выльется. Мне же не нужна была скорость, мне нужен был движок который будет предсказуемо и стабильно вести себя по мере роста. А сейчас так не пишут. Всем нужна скорость, возникли проблемы? Так купите SSD, добавьте память.
Коротко, на примере boltdb, через примерно полгода эксплуатации:
— нагрузка на винт под 100% (перестало работать всё остальное)
— деградация производительности в десятки — сотни раз
— необходимость покупки дорогостоящего SSD
— необходимость поднятия кеширующего слоя с redis над болтом
При этом boltdb — не самая плохая база данных, пока целиком помещалась в память — всё было прекрасно.
До этого обжигался на хранении бинарных данных (именно бинарных) в РСУБД + был не самый удачный опыт эксплуатации Касандры.
С другой стороны есть позитивный опыт эксплуатации sophia в хайлоаде, но она на C и замечания тоже есть. С leveldb сталкивался больше как пользователь, субъективно — мне показалась что она вобрала в себя все возможные недостатки) Проверять не стал. Архитектурно понравился badger, но оттолкнула модель хранения данных (Lsm Tree) и некоторые посты от их команды разработки. Банально не хотелось проверять на себе. Ну и задача разработки простенького движка — казалось проще чем оказалось)
Это целая наука, Ботов добавляют в storebot.me без особого эффекта, и в каталоги ботов типа botcollection.tggram.com, за деньги куда угодно можно впихнуть рекламу бота. Если денег нет — есть и бесплатные методы, типа втиснуть в комментарий к посту под благовидным предлогом. Но думаю Вас учить не надо этому
Большинство сайтов из России. Придут Иранцы, подниму поближе к ним сервер. Но надеюсь не придут, у них там Интернет говорят плохой, сайтами не пользуются
Что делает 1000 подписчиков, в канале, в котором нет постов, непонятно. Нет, бывают каналы реальные, без постов, с кучей подписчиков, но это не тот случай. К сожалению в бот апи нет чтения данных пользователей. Быстро выяснить кто все эти люди, не получилось.
Ага. Смотрел тоже и pico и h2o и всякие facilio — тлен это всё)
проще маленький нужный кусочек самому написать или стыбрить мякотку парсинга из подходящей либы
Ну и еще хотелось бы дополнить ложкой дегтя.
Экономишь — экономишь на сисколах, барахтаешься на самом дне, чтобы сэкономить жалкие 500 наносекунд, а потом видишь что десериализация объекта в перл жрет в 10 раз больше времени чем вся твоя убер система, и все равно все сводится к тому, что нужен кешик, уже в перле, над бд. И потом смотришь сверху на систему и понимаешь — что можно было ничего не менять, остаться на высоком ЯП, ибо конечная система все равно работает примерно с той же скоростью, лил.
Другими словами вот вы станцевали, а яваскрипт в http интерфейсе почты примерно так же тупит как раньше, например. И толку нет особо от всех этих танцев. Ну это я к примеру, может есть где то идеальный мир где всю систему пилит один человек и она работает максимально оптимально…
Вы, конечно, упоротые, в хорошем смысле этого слова.
До конца прошли путь на го, опустившись на самое дно. У нас была похожая ситуация — написали сокет сервер над http://sophia.systems/ на nim — https://github.com/recoilme/pudge
Но по мере написания, я чувствовал что мы опускаемся все ниже и ниже, переходя к ручному управлению памятью и погрязая в разборках как работает ним с епол и тп. В какой то момент я подумал что если мы все равно пишем на nim как на c — то почему бы не взять сразу готовую либу на си (libevent) и не скатиться в c окончательно?
Получился сокет сервер на си — https://github.com/recoilme/okdb Меня смущало еще то, что до этого я никогда не писал на си, у вас то с этим ситуация лучше), да это не проблема как выяснилось, си довольно простой. Работает без сбоев уже пол года — тьфу-тьфу-тьфу) Ну и знаете, кода и волшебных мест — стало меньше. Зато теперь я точно уверен что ни байта данных не расходуется «налево». Те может быть в вашей истории тоже не стоило упираться в гоу раз уж вам критичны ресурсы? Я просто профита от гоу не вижу здесь особо.
Коротко, на примере boltdb, через примерно полгода эксплуатации:
— нагрузка на винт под 100% (перестало работать всё остальное)
— деградация производительности в десятки — сотни раз
— необходимость покупки дорогостоящего SSD
— необходимость поднятия кеширующего слоя с redis над болтом
При этом boltdb — не самая плохая база данных, пока целиком помещалась в память — всё было прекрасно.
До этого обжигался на хранении бинарных данных (именно бинарных) в РСУБД + был не самый удачный опыт эксплуатации Касандры.
С другой стороны есть позитивный опыт эксплуатации sophia в хайлоаде, но она на C и замечания тоже есть. С leveldb сталкивался больше как пользователь, субъективно — мне показалась что она вобрала в себя все возможные недостатки) Проверять не стал. Архитектурно понравился badger, но оттолкнула модель хранения данных (Lsm Tree) и некоторые посты от их команды разработки. Банально не хотелось проверять на себе. Ну и задача разработки простенького движка — казалось проще чем оказалось)
Туповат как пробка, пришлось добавить свои костыли для поддержания беседы
Привет, я автор похожего сервиса. В вк лимит 3rps. Subscribe насколько я помню на теги и тп, вроде нет на новые посты в группе.
Превью пока планируется только для постов с телеграф.
Спасибо за отзыв
проще маленький нужный кусочек самому написать или стыбрить мякотку парсинга из подходящей либы
Экономишь — экономишь на сисколах, барахтаешься на самом дне, чтобы сэкономить жалкие 500 наносекунд, а потом видишь что десериализация объекта в перл жрет в 10 раз больше времени чем вся твоя убер система, и все равно все сводится к тому, что нужен кешик, уже в перле, над бд. И потом смотришь сверху на систему и понимаешь — что можно было ничего не менять, остаться на высоком ЯП, ибо конечная система все равно работает примерно с той же скоростью, лил.
Другими словами вот вы станцевали, а яваскрипт в http интерфейсе почты примерно так же тупит как раньше, например. И толку нет особо от всех этих танцев. Ну это я к примеру, может есть где то идеальный мир где всю систему пилит один человек и она работает максимально оптимально…
До конца прошли путь на го, опустившись на самое дно. У нас была похожая ситуация — написали сокет сервер над http://sophia.systems/ на nim — https://github.com/recoilme/pudge
Но по мере написания, я чувствовал что мы опускаемся все ниже и ниже, переходя к ручному управлению памятью и погрязая в разборках как работает ним с епол и тп. В какой то момент я подумал что если мы все равно пишем на nim как на c — то почему бы не взять сразу готовую либу на си (libevent) и не скатиться в c окончательно?
Получился сокет сервер на си — https://github.com/recoilme/okdb Меня смущало еще то, что до этого я никогда не писал на си, у вас то с этим ситуация лучше), да это не проблема как выяснилось, си довольно простой. Работает без сбоев уже пол года — тьфу-тьфу-тьфу) Ну и знаете, кода и волшебных мест — стало меньше. Зато теперь я точно уверен что ни байта данных не расходуется «налево». Те может быть в вашей истории тоже не стоило упираться в гоу раз уж вам критичны ресурсы? Я просто профита от гоу не вижу здесь особо.
В этом комментарии я покажу как подружить ваш сервис с телеграмом без мощных визуальных комбайнов.