glassman
Дмитрий Глазырин

(16) Такой задачи не стояло

(13)

Цитата
явно паразитное хранение одинаковых данных

Да, такая проблема есть. Еще там просится колонка с видом топлива на выход. Она условно-постоянная для резервуара. По оптимизации приема информации тоже думаем и обсуждаем.

(12)

Цитата
агрегирование чистым SQLэм

Наверное, вы правы. Я относительно не плохо знаю чистый SQL, но с остальными возможностями СУБД, про которые вы упомянули, я не дружен. Прошу относится к задачам как просто к примерам запросов разного уровня сложности, а не с точки зрения оптимальности решения конкретной задачи. Максимальный объем топлива в резервуаре для второй задачи, например, у нас известен и хранится отдельно. В реальности его нет смысла считать каждый раз как max() по всей таблице.

(7)

Цитата
Данные сначала приходят в него и только потом в Clickhouse (через пару минут). А напрямую нельзя, пробовали?

Можно напрямую, не думаю, что это будет проблемой для питонщиков. Но т.к. идея с резервным копированием была - делать копии ВМ, то разницу между резервными копиями где-то надо хранить. И почему бы для этого postgre не оставить?

Тесты на обновление/удаление записей не проводил. Где-то попадалось инфа, что это связано с высокой нагрузкой на процы/диски и работает медленнее обычных СУДБ в разы. У нас же тут только инсерты. Инсерты в CH очень быстрые. Не подсветил это в статье, но с добавлением записей Clickhouse более чем дружен. Так что узкого места на перегонке записей из одной бд в другую не ожидаю.

Скорость работы из 1С не сохранилась, к сожалению.

p.s. Спасибо за отзыв! Это исследование и планировалось так, чтобы обзорно охватить все этапы, которые надо будет пройти при внедрении и переходе. При этом наполнив максимумом конкретики. А то все что в интернете попадалось ограничивалось только общими словами. :)

(5) Спасибо за отзыв

(1)

Цитата
мы во внутренних решениях Инфостарт используем подключение отчетов к Clickhouse для работы с метриками для демо-доступов Инфостарт и нового сервиса 1С-Store

Оно подключается через драйвер ODBC. Но по отзывав там все не очень надежно.

Пожалуй, вы правы. Добавлю это в статью.

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать!
В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

Перезапуск служб/сервера не помогли. Помогла очистка кеша сеансовых данных (snccntx.... внутри папки srvinfo)

Почти все разработчики и консультанты сталкивались с задачами, связанных с обменом между базами через EnterpriseData (конвертация данных 3, обмен через универсальный формат и т.д.). Типовой механизм похож на черный ящик: что-то там долго-долго выгружает и выдает на выходе xml-файл циклопических размеров. А что в этом файле? Почему он такой большой? Что и сколько выгрузилось? Какие объекты занимают больше всего места? А можно ли вырезать ненужное? А можно ли разбить файл на части? А можно... А можно... На эти и многие другие вопросы ответит эта обработка!

Обработка для вызовов API Nanopool.org. Реализованы все методы для всех валют. Результаты методов парсятся в структуры. Есть пользовательский интерфейс (УФ) с возможностью задать параметры запроса и худо-бедно реализованным выводом результата на экран.