Расскажите пожалуйста про компактность хранения, какой выйгрыш получился при сравнимом объеме документов?
При этом компактность хранения данных и простота масштабирования хранилища всё же позволяют рассматривать Scylla для задач долговременного хранения и как вариант диверсификации зависимостей системы.
Рассматривали ли вы вариант реализацие tiered хранилища на монге (используя тэги при шардировании)? Или второй кластер монги под холодные данные. Это я к чему все.. Вы взяли незнакомую БД под архивные данные, хотя текущая БД доказала надежность и с её помощью можно реализовать hot-cold архитектуру данных. Хочу понять мотивацию :)
А расскажите пожалуйста, на каком железе работала монги и какой рпс она держала? Интересно в сравнении на вашем типе нагрузки. Ибо в своё время тоже рассматривал сциллу/кассандру как замену кластеру монги, но спустя неделю тестов каждой не получилось даже приблизиться к монговским рпс на запись (при +/- одинаковом железе).
"сразу нормально" это как? обычно приходится выбирать: или сразу, или нормально))
Тут и без кода понятно какую проблему автор решал для себя, и, в целом, единственная "нормальная" альтернатива - это sentry, но есть нюансы в виде непостоянства нашего интернета (да и мира в целом), а если разворачивать on premise - то выйдет дороже ELK.
Ну и да, описан специфичный кейс, который вполне может кому-нибудь пригодиться как идея. Доработать немного и будет легковесный менеджер ошибок.
а вот этот вот самопал из статьи на таком сетапе будет не оверинжениринг? :)
отнюдь. Это какая-никакая степень удобства по разбору ошибок вместо tail.
надо чинить, а не "складировать"
бесспорно, но речь в статье про "енотисы", которые возникают постоянно и не всегда в подконтрольном коде.
Сейчас конечно внедряется всякая кибана, но мне как-то надёжнее со своим простым сторожевым пёсиком
если есть ресурсы (и необходимость) на поддержку ELK - очень здорово, "сырые" логи перестают работать тогда, когда в инфре становится >=2 скриптовых машин и появляется необходимость в централизованной обработке логов.
Позволю себе ответить за автора цитатой из статьи: "Это отдельное ПО, которое нужно настраивать, поддерживать и оплачивать вычислительные мощности."
Если у меня простой L(A)MP (а то и шаред - так исторически сложилось) и CMS с тремя пользователями в день и один разраб - куда здесь эластик.. :) Оверинжениринг - лютое зло.
Описаный подход будет работать на небольших проектах с малым количеством ошибок. А если так, то и старый-добрый php-errors log можно поразбирать раз в день :)
Немного комментов по теме:
много отдельных маленьких файлов - плохо, тем более в одной директории. Что если использовать SQLite? Не потеряв в функционале и стабильности вы получите более удобную работу с данными и возможность расширения функционала в будущем;
мне, как разработчику, не хватает информации: как часто ошибка возникала и когда (время);
получать айди ошибки из текста+файла+строки, не самая лучшая идея. Например текст ошибки может содержать в себе переменную составляющую (типа Notice: Undefined offset: 102 <<), то же самое и со строкой - она может меняться при изменении вышестоящего кода;
при возникновении ошибки необходимо всё-таки её проверять во всех директориях (ignore, processed, system) - в статье мы проверяем только processed;
не вешайте на хэндлер ошибок слишком много (в статье вы допускаете отправку почты на возникновение ошибки). В идеале хэндлер должен содержать в себе какой-то один условный сисколл (типа запись в файл) и не заниматься поиском файликов в разных директориях, итп.
Знания того или иного языка != умению применить их в реализации той или иной задачи, увы) В моей жизни встречались разработчики, которые так глубоко закапывались в нюансы разработки, что порой забывали что они на самом деле делают. А ведь бизнесу нужен не классный код с применением самых модных паттернов, а, всё-таки, продукт.
В php прийдя на новый проект я могу через пару дней работы с кодом сказать об уровне команде и косяках в проекте.
Очень сомнительное заявление, особенно про уровень команды, не обессудьте :)
Нельзя NoSQL засунуть в парадигму ORM, ибо вторая буква тут никак не применима. Посмотрите в сторону доктриновского ODM. Но и то всё это выглядит крайне костыльно, увы.
Не вижу чтобы тмакс говорил что праймари может стать арбитром. Арбитр в схеме с primary+secondary+arbiter нужен только лишь для создания кворума. Такую схему обычно запускают когда в распоряжении имеется ограниченное кол-во ресурсов: 2 «большие» машины под мастер и слейв и одна мелкая под арбитр. В идеальном мире нужно всё-таки стремиться запускать схему master-secondary-secondary, причём не обязательно что третий secondary должен участвовать в выборах, главное чтобы он мог голосовать. Его так же можно сделать отстающей репликой на случай факапа в основной связке мастер-слейв — с него можно будет восстановить данные. Такой а-ля бэкап получается.
есть, балансировка проиходит на уровне драйвера в приложении (либо на уровне mongos в случае с sharded-cluster). Управляется указанием read preference при запросе, если просто указываем secondaryPreferred, то там юзается раундробин между репликами емнип.
на самом деле есть write concern, который определяет минимальное кол-во acknowledgment'ов для успешной записи. Касательно map-reduce — эта операция не распределяется между нодами в реплика-сете (куда пришли, там и сделали)
можно подключать/отключать налету. При первом подключении нода перейдёт в режим синхронизации и будет синкаться с мастера, а после завершения досинкается из бинлога (oplog) — тут важно чтобы длины оплога хватило по времени синхронизации.
так нельзя) Арбитром не становятся — им рождаются (ну или ручками можно сконвертить).
If your app enables people to purchase goods or services that will be consumed outside of the app, you must use purchase methods other than IAP to collect those payments ...
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
Если вы не продаёте offline-сервисы то Apple не даст сделать свой биллинг (карточный/смсный/..), придётся пользоваться их подписками. А подписки у них в техническом плане та ещё боль.
Если у вас продукт действительно ограничен в использовании по времени (либо некие периодические издания журналов/книг/итп), то проблем при ревью возникнуть не должно.
Просто оставлю это тут https://selectel.ru/blog/databases-types/
Автор указал это в самом начале статьи в разделе "Мотивация".
Это Rндекс.. хотя тоже не уверен что она тут к месту)
Спасибо за ответ и за статью!
Расскажите пожалуйста про компактность хранения, какой выйгрыш получился при сравнимом объеме документов?
Рассматривали ли вы вариант реализацие tiered хранилища на монге (используя тэги при шардировании)? Или второй кластер монги под холодные данные. Это я к чему все.. Вы взяли незнакомую БД под архивные данные, хотя текущая БД доказала надежность и с её помощью можно реализовать hot-cold архитектуру данных. Хочу понять мотивацию :)
А расскажите пожалуйста, на каком железе работала монги и какой рпс она держала? Интересно в сравнении на вашем типе нагрузки. Ибо в своё время тоже рассматривал сциллу/кассандру как замену кластеру монги, но спустя неделю тестов каждой не получилось даже приблизиться к монговским рпс на запись (при +/- одинаковом железе).
Определиться с чем? :)
"сразу нормально" это как? обычно приходится выбирать: или сразу, или нормально))
Тут и без кода понятно какую проблему автор решал для себя, и, в целом, единственная "нормальная" альтернатива - это sentry, но есть нюансы в виде непостоянства нашего интернета (да и мира в целом), а если разворачивать on premise - то выйдет дороже ELK.
Ну и да, описан специфичный кейс, который вполне может кому-нибудь пригодиться как идея. Доработать немного и будет легковесный менеджер ошибок.
отнюдь. Это какая-никакая степень удобства по разбору ошибок вместо tail.
бесспорно, но речь в статье про "енотисы", которые возникают постоянно и не всегда в подконтрольном коде.
если есть ресурсы (и необходимость) на поддержку ELK - очень здорово, "сырые" логи перестают работать тогда, когда в инфре становится >=2 скриптовых машин и появляется необходимость в централизованной обработке логов.
Позволю себе ответить за автора цитатой из статьи: "Это отдельное ПО, которое нужно настраивать, поддерживать и оплачивать вычислительные мощности."
Если у меня простой L(A)MP (а то и шаред - так исторически сложилось) и CMS с тремя пользователями в день и один разраб - куда здесь эластик.. :) Оверинжениринг - лютое зло.
Описаный подход будет работать на небольших проектах с малым количеством ошибок. А если так, то и старый-добрый php-errors log можно поразбирать раз в день :)
Немного комментов по теме:
много отдельных маленьких файлов - плохо, тем более в одной директории. Что если использовать SQLite? Не потеряв в функционале и стабильности вы получите более удобную работу с данными и возможность расширения функционала в будущем;
мне, как разработчику, не хватает информации: как часто ошибка возникала и когда (время);
получать айди ошибки из текста+файла+строки, не самая лучшая идея. Например текст ошибки может содержать в себе переменную составляющую (типа Notice: Undefined offset: 102 <<), то же самое и со строкой - она может меняться при изменении вышестоящего кода;
при возникновении ошибки необходимо всё-таки её проверять во всех директориях (ignore, processed, system) - в статье мы проверяем только processed;
не вешайте на хэндлер ошибок слишком много (в статье вы допускаете отправку почты на возникновение ошибки). В идеале хэндлер должен содержать в себе какой-то один условный сисколл (типа запись в файл) и не заниматься поиском файликов в разных директориях, итп.
Знания того или иного языка != умению применить их в реализации той или иной задачи, увы) В моей жизни встречались разработчики, которые так глубоко закапывались в нюансы разработки, что порой забывали что они на самом деле делают. А ведь бизнесу нужен не классный код с применением самых модных паттернов, а, всё-таки, продукт.
Очень сомнительное заявление, особенно про уровень команды, не обессудьте :)
https://github.com/lazyjsonmapper/lazyjsonmapper
Не совсем понял. За что их банить, если нет подписок?)
Если у вас продукт действительно ограничен в использовании по времени (либо некие периодические издания журналов/книг/итп), то проблем при ревью возникнуть не должно.
Это не совсем так. Для того чтобы отдать приложение на внешнее тестирование существует TestFlight Beta Testing