Statsd может дополнительную агрегацию делать и считать всякие средние в разных временных окнах. Коллект этого не делает. Соответственно в базу поступает не просто и не только значения, а еще и параметризированные результаты. Ну, это если нужно.
pavvel2: ну работают же на нем (даже я!), просто порог вхождения не очень низкий, как например у вордпресс или джомлы или модх.
во всяком случае всегда можно всзять на пробу - триальный период.
CSSwaR: Собственно полностью согласен с MiiNiPaa:
Производители не держат в открытом доступе протоколы обмена. Да и под NDA дадут совсем не каждому. Но сам протокол CAN открытый, информации по нему полно. Дерзайте (или ну его нафиг).
Протокол CAN и анализатор вам в руки. Читать, читать и читать... И... по моему... Да ну его нафиг... Если это не как идея бизнеса или повод устроиться на Афтотаз.
pavvel2: dev.1c-bitrix.ru/support/forum/forum6/topic52741 немного криво, но она есть.
По поводу ужас-ужас, это первое.
2) ужасный дизайн в плане архитектуры, сплошной copy-paste
3) Все в одной куче, и код и шаблоны
4) Если нужно что-то поменять - copy-paste
5) есть темплейты, но - copy-paste
6) есть компоненты, но - copy-paste
7) Все изменения, если сайт действительно типа портала разбросаны по 20-30 местам, здесь обработчики, здесь компоненты, здесь шаблоны, здесь куча говна, и еще так в 15 мест прописать
8) ajax - просто песня! написал свое! похоже, даже разработчики не всегда понимают - зачем оно так (ведь есть и jquery на худой конец).
9) наследуемость, она как бы есть, но - copy-paste
10) не дай ты бог, что-то экстраординарное (а оно постоянно), документация как бы есть, и даже очень богатая, но без примеров - запишись на курсы, просмотри 100 наших замечательных видео и будет щазтие
11) это как так, элементы и разделы только для себя самих?! хочешь связать элемент с разделом из другого инфоблока - только через внешнюю связку!!!! Другими словами - у каждого типа документа отдельные разделы, у каждого Карл! И они никак, никак Карл, не связываются напрямую!!
12) Вы еще не делали меню? Тогда мы идем к вам!
Блин!!! 10 лет назад это была свежая и классная архитектура для тех языков программирования и возможностей.
Да вроде бы никакого криминала в этом коде нет.
Какой-то однозначной "правильной" архитектуры, на все случаи жизни, увы, не знаю, да думаю, что такой и не будет никогда. Ну а про разновидности проектирования говорить можно очень и очень долго. Кто-то вообще на микросервисы переходит почти во всем...
kacang: Нет, иногда совсем не одно и тоже... Особенно, если хитрый сервер делает ограничение на коннект по скорости. Ну и непример, так удобнее сканировать несколько папок (у меня их около 50).
Олег: И да, иногда легче еще один сервер поставить с приложением, чем переносить базу на новый.. Ибо иногда это деньги и немалые за лицензии... Так что грузить лишний раз сервер баз данных не нужно, пусть себе работает, а резервный - отдыхает.
Олег: Ух... С высоты моего скромного опыта, хранимки и тригерры - зло неимоверное! Непереносимое, неконтролируемое, глючное, абсолютно не расширяемое, пережиток динозавров. По каждому пункту могу целую статью написать с примерами, почему так никогда, никогда не нужно делать.
Как пример - бизнес-система, программисты добавили немного данных в новые таблицы, привязали через вторичные ключи, залили новые данные по клиентам, а дурацкий триггер с этой вот самой хранимкой, ранее несколькими днями добавленный одним нехорошим человеком, взял и списал с нескольких тысяч клиентов малую денюжку. Откат базы данных и накат транзакций за услуги занял без малого тройку дней с кофем, матючком и куртизанками. Триггер просто вылидировал данные, но блокировал при этом отдельные поля и таблицы, а хранимка по откату пыталась вадидировать счет.
И это при том, что все было 10 раз проверено, оттестировано, отлажено и прочая прочая...
Не делайте так никогда. Тогда данные всегда будут правильные и пушистые, транзакции быстры и точны.
0LLEGator: Более того, база данных одна, а приложений может быть несколько, да на разных серверах. Так что чаще бывает просто выдернуть данные, их закешировать и обрабатывать. Но конечно же все зависит от данных, и прочих разных условий.
0LLEGator: Ну, не всегда так. Бывает, что чтобы отсортировать сотню записей (из нескольких миллионов) нужно так за ипачить запрос, что он не попадет в индексы, просрёт все кеши и будет по данным шуршать пол часа. Раньше выходили из этого положения созданием временных таблиц, но нонче это не особо модно, так как запросов таких может быть иной раз тышу в секунду. Так что я предпочитаю выдернуть поболее, в переделах разумного, и фильтрануть программно, когда это позволительно.
Да и не всегда можно запрос сделать, увы...
0LLEGator: Ну... а кто мешает второй столбец замутить? Да если и один, перебрать их программно гораздо легче, чем городить супер-пупер-сиквел-запросы, тем более, что не будет же у них 100 посетителей/секунда... А если будет, то здесь уже и кеширование понадобится и всё равно рабоатть быстрее будет по простой выборке (с кешированием конечно).
pixik: Вариантов несколько, разделяй и властвуй. Вытащи данные, конвертни и отобрази. Ну а если R использовать, то там и свой обработчик написать можно. Конверитироавть можно почти всем, начиная от awk и заканчивая python.
Кстати о последнем - для него есть замечательная весчь - numpy и scipy. Последняя тоже рисовать умеет.
