Comments 53
Статья оставляет впечатление недосказанности:
- Во-первых, зачем для сервиса накопления и анализа логов Cassandra? Почему нельзя было взять тот же Flume и спокойно грузить данные в HDFS, а там их с тем же успехом обрабатывать в MR?
- Картинки исходной и целевой архитектуры не имеют общих компонент, сложно понять куда именно (и как) вы подключили Cassandra
- 300млн записей за 100 минут — какого рода обработка проводится? Мой ноутбук может спокойно распарсить 300млн строк лога за 7-8 минут на одном ядре. Обработка очень сложная с подтягиванием данных из внешних систем?
- Показатели производительности без указания характеристик кластера смотрятся немного странно
- На графиках не подписаны оси и что где меряется непонятно
- Основной показатель производительности для Cassandra — это обычно количество операций в секунду и latency операций (average и перцентили p99, p995, p999, p9999), эти графики были бы самыми интересными
Договор NDA с заказчикам не позволяет все детализировать, я все таки попробую отвечать на ваше все вопросы:
>>> Во-первых, зачем для сервиса накопления и анализа логов Cassandra? Почему нельзя было взять тот же Flume и спокойно грузить данные в HDFS, а там их с тем же успехом обрабатывать в MR?
Из за репликация данных между ЦОД, система работал в 7 регионах страны и часто было свой каналов между ЦоД, У Cassnadra из коробки есть возможности хранить данный в локальных узлах и при появление канал связи Cassandra может передавать и синхронизировать данные между узлами кластера (hinted handhof). Если через flume тогда необходимо было хранить все эти данные в Oracle ExaData, серверные диски было довольно дорогие, нам еще бы нужно было вычислить промижуточные данные во время свой канал связи между ЦОД.
>>> Картинки исходной и целевой архитектуры не имеют общих компонент, сложно понять куда именно (и как) вы подключили Cassandra
Cassandra установлись в каждом регионе, стратегия NetworkTopologyStrategy, репликация между дата центрами.
>>> 300млн записей за 100 минут — какого рода обработка проводится? Мой ноутбук может спокойно распарсить 300млн строк лога за 7-8 минут на одном ядре. Обработка очень сложная с подтягиванием данных из внешних систем?
в основном группировка данных, большее 9 groupBy а также во время reduce в обновили данных в Cassandra таблицу
>>> Показатели производительности без указания характеристик кластера смотрятся немного странно
Cassandra сервер: 4 CPU, 8 Gb Ram, virtual machine
Hadoop data node: 6 cpu, 16 Gb RAM, virtual machine
>>> На графиках не подписаны оси и что где меряется непонятно
оси X — время в минутах
оси Y — количества строк в таблице
>>> Во-первых, зачем для сервиса накопления и анализа логов Cassandra? Почему нельзя было взять тот же Flume и спокойно грузить данные в HDFS, а там их с тем же успехом обрабатывать в MR?
Из за репликация данных между ЦОД, система работал в 7 регионах страны и часто было свой каналов между ЦоД, У Cassnadra из коробки есть возможности хранить данный в локальных узлах и при появление канал связи Cassandra может передавать и синхронизировать данные между узлами кластера (hinted handhof). Если через flume тогда необходимо было хранить все эти данные в Oracle ExaData, серверные диски было довольно дорогие, нам еще бы нужно было вычислить промижуточные данные во время свой канал связи между ЦОД.
>>> Картинки исходной и целевой архитектуры не имеют общих компонент, сложно понять куда именно (и как) вы подключили Cassandra
Cassandra установлись в каждом регионе, стратегия NetworkTopologyStrategy, репликация между дата центрами.
>>> 300млн записей за 100 минут — какого рода обработка проводится? Мой ноутбук может спокойно распарсить 300млн строк лога за 7-8 минут на одном ядре. Обработка очень сложная с подтягиванием данных из внешних систем?
в основном группировка данных, большее 9 groupBy а также во время reduce в обновили данных в Cassandra таблицу
>>> Показатели производительности без указания характеристик кластера смотрятся немного странно
Cassandra сервер: 4 CPU, 8 Gb Ram, virtual machine
Hadoop data node: 6 cpu, 16 Gb RAM, virtual machine
>>> На графиках не подписаны оси и что где меряется непонятно
оси X — время в минутах
оси Y — количества строк в таблице
С появлением в картинке Exadata и разворачиванием Cassandra+Hadoop на виртуальных машинах ситуация начинается проясняться. Я не в курсе истории, но скорее всего она выглядела приблизительно так:
Если серьезно:
- Заказчик играет тендер на ПАК и закупает Exadata. Счастливые закупщики на полученные откаты идут строить дачи и покупать новые машины (7 кластеров Exadata — это не шутка, десятки миллионов долларов)
- Затем играется тендер на разработку софта, на остатки проектного бюджета. Исполнителям понятно, что хранить и обрабатывать логи в Exadata — это дикость, да и места может не хватить, поэтому для снижения расходов на имеющейся у заказчика инфраструктуре разворачивается ряд open source продуктов
- Естественно, имеющаяся инфраструктура — это отрезать кусочек от какого-нибудь VDI и недорогого СХД и запустить там виртуалки с Cassandra/Hadoop поверх shared storage
- У исполнителя опыта немного да и бюджет не резиновый, поэтому берется софт, пусть и не подходящий, зато умеющий много «из коробки»
- С горем пополам и из рук вон плохой производительностью система сдается и идет в production
Если серьезно:
- Cassandra для накопления и batch processing логов вообще никаким боком не нужна
- Такая система собирается за неделю на том же Flume. Вы удивитесь, но данные в случае обрыва канала он тоже хранить умеет
- Вместо одной стойки Exadata за те же деньги закупается кластер Hadoop на 100 нод с поддержкой Hortonworks/Cloudera
- Для запросов с 9 group by существуют отдельный класс систем поверх Hadoop, которые умеют делать pipelining лучше чистого MapReduce — это Hive+Tez, Cloudera Impala, SparkSQL, Apache HAWQ
- По производительности — на скромном кластере в 20 нод агрегация не 300 миллионов, а 300 миллиардов записей лога делается за <30 минут
Если сейчас поставили задачи для решения таких проблем, я бы проектировал его по другому.
>>> По производительности — на скромном кластере в 20 нод агрегация не 300 миллионов, а 300 миллиардов записей лога делается за <30 минут
проблема было еще с Cassandra и Pig (data flow). У cassandra еще не было готово выборки данных через where clause. Pig в любой обработки подтянул все данные (хоть это млрд)и после этого pig начал фильтрации обработки.
>>> По производительности — на скромном кластере в 20 нод агрегация не 300 миллионов, а 300 миллиардов записей лога делается за <30 минут
проблема было еще с Cassandra и Pig (data flow). У cassandra еще не было готово выборки данных через where clause. Pig в любой обработки подтянул все данные (хоть это млрд)и после этого pig начал фильтрации обработки.
Hadoop крутится в виртуалке? Вроде везде пишут, что никаких прослоек и виртуализаций если хотите производительность
UPD: Прочитал выше, если виртуалки — это все, что было, тогда, видимо, выбора было не много.
UPD: Прочитал выше, если виртуалки — это все, что было, тогда, видимо, выбора было не много.
Т.е. рост практически линейный? Получается, если будет 3 млрд строк, то за сутки не уложиться? А Вы производите агрегацию в одном месте или в дата-центрах на местах, и уже агрегаты доставляете в центр? Агрегируется все или каждая 100-я или 1000-я строка лога (если это не лог фин. операций, к примеру, то не всегда нужно агрегировать все строки).
> на базе NoSQL успешно реализованы тысячи проектов
Из них 990 — проекты для записи и анализа логов?
Из них 990 — проекты для записи и анализа логов?
Есть опыт интеграции в СМЭВ. Это сущий ад, который не заканчивается уже 9 месяцев ради 3х простых сервисов. Боюсь никакие улучшения системы логирования вам не помогут.
Правильнее сказать «не помогли» — впереди СМЭВ 3, с другой идеологией и от другого разработчика.
Может поделитесь какие у вас были сложности с интеграцию?
Задача простая — реализовать средство идентификации пользователей электронного кошелька. Для этого были найдены три сервиса: SID0003450 (ИНН), SID0003822 (СНИЛС), SID0003418 (Проверка паспорта через ФМС).
Так вот, сначала ждешь ключи N времени (месяца полтора). Пока ты их ждешь ничего, конечно же, сделать нельзя потому что сервер на котором лежала документация был не доступен 2 недели. (Кажется было в Марте.) Потом качаешь доку в DOC формате, в которая хоть и в архиве, но именно в нее закинуты файлы с примерами, без которых работать сложно. Когда у тебя Mac, то процесс извлечения файлов заключается в нахождении друга с Windows и просьбой его все оттуда выковырять.
А когда ключи приходят делаешь два простых сервиса, а потом оказывается что есть отдельные ключи на один из сервисов (ФМС). По этому сервису нас перенаправляет поддержка со СМЭВа в ФМС, ФМС потом к людям, которые писали им софт (какого?), последние отфутболивают обратно, где нам больше не отвечают 4 месяца.
Это только та часть проблем, которую я помню. Даже не говорю о необходимости ставить CryptoPro и мучиться потом с ним. В основном бюрократия, но и технических «странностей» у вас хватает.
Так вот, сначала ждешь ключи N времени (месяца полтора). Пока ты их ждешь ничего, конечно же, сделать нельзя потому что сервер на котором лежала документация был не доступен 2 недели. (Кажется было в Марте.) Потом качаешь доку в DOC формате, в которая хоть и в архиве, но именно в нее закинуты файлы с примерами, без которых работать сложно. Когда у тебя Mac, то процесс извлечения файлов заключается в нахождении друга с Windows и просьбой его все оттуда выковырять.
А когда ключи приходят делаешь два простых сервиса, а потом оказывается что есть отдельные ключи на один из сервисов (ФМС). По этому сервису нас перенаправляет поддержка со СМЭВа в ФМС, ФМС потом к людям, которые писали им софт (какого?), последние отфутболивают обратно, где нам больше не отвечают 4 месяца.
Это только та часть проблем, которую я помню. Даже не говорю о необходимости ставить CryptoPro и мучиться потом с ним. В основном бюрократия, но и технических «странностей» у вас хватает.
Меня вот всегда потрясало, что — несмотря на системы логирования, аудит, вот это вот всё — любое общение с ТП СМЭВ все равно начиналось с «пришлите трейс запроса/ответа». И отдельно — «контрольные примеры» во всех РП.
Служба эксплуатации тогда еще не было готов пользоваться CQL запросами чтобы вытащить данные из Cassandra таблицы, поэтому часто для оперативной работы спрашивали «пришлите трейс запроса/ответа»
К сожалению, в моем опыте это было не «часто для оперативной работы», а всегда. Иными словами тикет в ТП не открывали без запроса/ответа. Нам пришлось сделать свою систему сквозного логирования, чтобы решить эту проблему.
Удивительно, что в задании не был изначально заложен интерфейс.
Служба эксплуатации тогда еще не было готов пользоваться CQL запросами чтобы вытащить данные из Cassandra таблицы
Удивительно, что в задании не был изначально заложен интерфейс.
если это начале 2011 года, да было организационная проблема.
>>> Это только та часть проблем, которую я помню. Даже не говорю о необходимости ставить CryptoPro и мучиться потом с ним.
по моему эту жалобу относится к CryptoPro а не к СМЭВ
>>> Это только та часть проблем, которую я помню. Даже не говорю о необходимости ставить CryptoPro и мучиться потом с ним.
по моему эту жалобу относится к CryptoPro а не к СМЭВ
Все эти причины сподвигли нас пересмотреть нашу архитектуру и перейти на NoSQL.
Почему именно NoSQL, а не другая SQL СУБД?
Из за репликация данных между ЦОД, система работал в 7 регионах страны и часто было свой каналов между ЦоД, У Cassnadra из коробки есть возможности хранить данный в локальных узлах и при появление канал связи Cassandra может передавать и синхронизировать данные между узлами кластера (hinted handhof). А также масштабируемость системы было критично.
Поверить не могу, что гири на КДПВ могут так стоять. Фантастика.)
Вот это картинка! Супер! В пост защёл только чтобы восхититься и написать комент.
Хоть убей, не пойму, при чем здесь NoSQL.
Появилась связь между узлами большого кластера. NoSQL база перераспределила данные на разные узлы кластера.
Совсем не факт, что данные одного центра обработки данных будут находится на узлах данного центра, а не утекут безвозвратно в другой центр данных. При потере связи, текущий центр теряет часть своих данных.
Мой старый блог «Apache CXF и ЭЦП для SOAP сообщений СМЭВ».
Появилась связь между узлами большого кластера. NoSQL база перераспределила данные на разные узлы кластера.
Совсем не факт, что данные одного центра обработки данных будут находится на узлах данного центра, а не утекут безвозвратно в другой центр данных. При потере связи, текущий центр теряет часть своих данных.
Мой старый блог «Apache CXF и ЭЦП для SOAP сообщений СМЭВ».
>>> Совсем не факт, что данные одного центра обработки данных будут находится на узлах данного центра, а не утекут безвозвратно в другой центр данных
Речь идет о Cassandra Replication
вот вам 2 пример
create keyspace p00skimKS
with strategy_class='NetworkTopologyStrategy'
and strategy_options:p00smevDC = 0 and strategy_options:p00skimDC = 1;
— create keyspace p00smev_archKS
with strategy_class='NetworkTopologyStrategy'
and strategy_options:p00smevDC = 1 and strategy_options:p00skimDC = 0;
на первом примере данные не когда не будет реплицироваться в дата центре p00smevDC, а на втором примере нет. Есть хорошая документация в cassandra planet www.datastax.com/dev/blog/multi-datacenter-replication (раздел Geographical Location Scenario)
>>> Мой старый блог «Apache CXF и ЭЦП для SOAP сообщений СМЭВ».
причем тут это не очень понял ))
Речь идет о Cassandra Replication
вот вам 2 пример
create keyspace p00skimKS
with strategy_class='NetworkTopologyStrategy'
and strategy_options:p00smevDC = 0 and strategy_options:p00skimDC = 1;
— create keyspace p00smev_archKS
with strategy_class='NetworkTopologyStrategy'
and strategy_options:p00smevDC = 1 and strategy_options:p00skimDC = 0;
на первом примере данные не когда не будет реплицироваться в дата центре p00smevDC, а на втором примере нет. Есть хорошая документация в cassandra planet www.datastax.com/dev/blog/multi-datacenter-replication (раздел Geographical Location Scenario)
>>> Мой старый блог «Apache CXF и ЭЦП для SOAP сообщений СМЭВ».
причем тут это не очень понял ))
Пример интересный.
Первый пример — p00skimKS. Вы запрещаете перетекание данных в другой дата центр.
Второй пример — p00smev_archKS. Вы запрещаете распределять в текущем дата центре и разрешаете отдавать в другой дата центр.
Из двух примеров получается как минимум дубликат своих данных в двух разделах. Допустим, нам места на диске не жалко. Но у нас несколько внешних дата центров и для каждого надо подготовить свой набор данных, которые надо отдать. Получаем картину из кучи N+1 разделов.
N — количество внешних дата центров. +1 — это текущий дата центр. И первый из N — это общий (федеральный) центр.
Может я и не прав. Не проще ли реализовать аналог почтового сервера, или MQ сервера, с указанием адресатов доставки? Затрат на распределение данных по разным разделам меньше.
Можно заменить SMTP или MQ сервер на FTP сервер. Выкладывать данные для других центров на ftp обменник. И принимаемый дата центр сам решает проблему, как обрабатывать эти данные. То есть, не завязаны на использование одного ПО.
Далее, технология MapReduce. Да, это модно и потому, круто. Но почему графика не в виде логарифма, а в виде прямой линии? По мне, всё дело в этой технологии. Хотим добиться увеличения скорости за счет обработки данных текущего узла кластера. Но на поверку получаем обратный эффект. Каждый узел имеет часть данных другого узла. Другими словами, при 3-х уровневой репликации данных, мы получаем полных 3 прохода обработки одних и тех же данных. Проще было бы получить поток не повторяющихся данных. И этот поток нарезать на кучу потоков в одном узле и на несколько узлов.
Первый пример — p00skimKS. Вы запрещаете перетекание данных в другой дата центр.
Второй пример — p00smev_archKS. Вы запрещаете распределять в текущем дата центре и разрешаете отдавать в другой дата центр.
Из двух примеров получается как минимум дубликат своих данных в двух разделах. Допустим, нам места на диске не жалко. Но у нас несколько внешних дата центров и для каждого надо подготовить свой набор данных, которые надо отдать. Получаем картину из кучи N+1 разделов.
N — количество внешних дата центров. +1 — это текущий дата центр. И первый из N — это общий (федеральный) центр.
Может я и не прав. Не проще ли реализовать аналог почтового сервера, или MQ сервера, с указанием адресатов доставки? Затрат на распределение данных по разным разделам меньше.
Можно заменить SMTP или MQ сервер на FTP сервер. Выкладывать данные для других центров на ftp обменник. И принимаемый дата центр сам решает проблему, как обрабатывать эти данные. То есть, не завязаны на использование одного ПО.
Далее, технология MapReduce. Да, это модно и потому, круто. Но почему графика не в виде логарифма, а в виде прямой линии? По мне, всё дело в этой технологии. Хотим добиться увеличения скорости за счет обработки данных текущего узла кластера. Но на поверку получаем обратный эффект. Каждый узел имеет часть данных другого узла. Другими словами, при 3-х уровневой репликации данных, мы получаем полных 3 прохода обработки одних и тех же данных. Проще было бы получить поток не повторяющихся данных. И этот поток нарезать на кучу потоков в одном узле и на несколько узлов.
График никакого отношения к MapReduce не имеет. Он лишь показывает, что используемый алгоритм обработки данных линейно зависит от количества входных данных. Тут не важно, работает ли он на кластере или на одной машине.
Почему 3 прохода обработки? При записи данных в HDFS вы действительно записываете данные 3 раза на 3 разных машинах, но делается это не последовательно, а параллельно. При чтении вычитывается только одна копия и чаще всего локальная для обработчика, другие копии хранятся для отказоустойчивости и speculative execution
Почему 3 прохода обработки? При записи данных в HDFS вы действительно записываете данные 3 раза на 3 разных машинах, но делается это не последовательно, а параллельно. При чтении вычитывается только одна копия и чаще всего локальная для обработчика, другие копии хранятся для отказоустойчивости и speculative execution
0x0FFF, поддерживаю, все верно.
Линейная зависимость обработки данных от количества обрабатываемых данных, это главная проблема.
Если бы была экспонента, было бы очень плохо. А вот логарифм — это то, к чему надо стремиться.
То есть, затраты растут гораздо ниже, чем объем данных. Я по оси X представляю объем данных, а по оси Y объем затрат или время обработки.
Для этого нужно отказываться от последовательной обработки данных.
Пример. У вас на машине 4 ядра.
1) Последовательно берем данные, обрабатываем, отправляем куда-то.
2) Если это не конец данных, возвращаемся к первому пункту.
Итого: у нас занято 1 ядро, а 3 простаивает.
Это не эффективно. Надо организовывать очередь из задач обработки и определять набор обработчиков. Так мы загрузим все 4 ядра и тем самым увеличим скорость обработки данных. У нас уже не получится линейного графика. Он будет больше напоминать логарифмическую кривую. При этом, части получения исходных данных и отправки результата, могут остаться последовательными.
На самом деле, на 4-х ядрах можно использовать несколько десятков обработчиков (потоков).
Ну ни как не получается у меня прямой линии. Что я делаю не так?
Честно, в статье так и сказано. У нас был Oracle и он работал быстро. И вот однажды нам его стало не хватать. Мы решили поставить вместо одного Oracle кучу NoSQL машин. О чудо, система стала быстрее работать. Но чуда нет. Производительность системы растет линейно. Нам нужно поставить еще несколько физически/виртуальных машин.
>> У этой системы был ряд недостатков:
>> Плохая массштабируемость: первой проблемой стала динамика роста регистраций и использование сервисов во всех органах власти.
Вы сократили время обработки одного запроса, но с задачей увеличения производительности не справились.
>> После настройки (fine tuning) Hadoop мы получили такие производительности. Разбор 300 млн строк из Cassandra занимает примерно 100 минут. Построение агрегата на 300 млн записей занимает в среднем 170 мин.
Hadoop — это ваш MapReduce. А вы мне, «График никакого отношения к MapReduce не имеет».
Если бы была экспонента, было бы очень плохо. А вот логарифм — это то, к чему надо стремиться.
То есть, затраты растут гораздо ниже, чем объем данных. Я по оси X представляю объем данных, а по оси Y объем затрат или время обработки.
Для этого нужно отказываться от последовательной обработки данных.
Пример. У вас на машине 4 ядра.
1) Последовательно берем данные, обрабатываем, отправляем куда-то.
2) Если это не конец данных, возвращаемся к первому пункту.
Итого: у нас занято 1 ядро, а 3 простаивает.
Это не эффективно. Надо организовывать очередь из задач обработки и определять набор обработчиков. Так мы загрузим все 4 ядра и тем самым увеличим скорость обработки данных. У нас уже не получится линейного графика. Он будет больше напоминать логарифмическую кривую. При этом, части получения исходных данных и отправки результата, могут остаться последовательными.
На самом деле, на 4-х ядрах можно использовать несколько десятков обработчиков (потоков).
Ну ни как не получается у меня прямой линии. Что я делаю не так?
Честно, в статье так и сказано. У нас был Oracle и он работал быстро. И вот однажды нам его стало не хватать. Мы решили поставить вместо одного Oracle кучу NoSQL машин. О чудо, система стала быстрее работать. Но чуда нет. Производительность системы растет линейно. Нам нужно поставить еще несколько физически/виртуальных машин.
>> У этой системы был ряд недостатков:
>> Плохая массштабируемость: первой проблемой стала динамика роста регистраций и использование сервисов во всех органах власти.
Вы сократили время обработки одного запроса, но с задачей увеличения производительности не справились.
>> После настройки (fine tuning) Hadoop мы получили такие производительности. Разбор 300 млн строк из Cassandra занимает примерно 100 минут. Построение агрегата на 300 млн записей занимает в среднем 170 мин.
Hadoop — это ваш MapReduce. А вы мне, «График никакого отношения к MapReduce не имеет».
У вас есть процессор. Максимально он может выполнить X инструкций в секунду, чем больше ядер тем больше X. У вас есть входные данные в количестве Y записей. Если на обработку каждой записи тратится C операций процессора, то на этом процессоре максимум вы сможете обработать Y*C/X операций в секунду. Не важно, 20 или 20000 потоков у вас, процессор быстрее не станет и выполнять больше X операций он не сможет физически. Итого Runtime = Y*C/X. Увеличив Y в 2 раза получим Runtime = 2*Y*C/X, что в два раза больше. Если у нас не один процессор, а 1000, это не изменит картины. Будет время выполнения Y*C/(1000*X) и 2*Y*C/(1000*X), то есть при росте количества данных в 2 раза все равно производительность упадет в 2 раза.
Это называется асимптотическая сложность алгоритма O(N). К таким алгоритмам и относится чаще всего алгоритм парсинга логов — вы не сможете получить меньше O(N), т.к. вам нужно как минимум один раз прочитать каждую строчку входных данных. Я не отрицаю, есть алгоритмы сложностью меньше O(N), допустим тот же поиск в сбалансированном дереве с характеристикой O(logN), или даже на дереве ван Эмде Боаса со сложностью O(log(logN)), но все алгоритмы с sublinear complexity не являются не алгоритмами обработки данных, а алгоритмами поиска.
Да, и не «вы» — система-то в общем не моя, я скорее сам критикую их архитектуру.
Это называется асимптотическая сложность алгоритма O(N). К таким алгоритмам и относится чаще всего алгоритм парсинга логов — вы не сможете получить меньше O(N), т.к. вам нужно как минимум один раз прочитать каждую строчку входных данных. Я не отрицаю, есть алгоритмы сложностью меньше O(N), допустим тот же поиск в сбалансированном дереве с характеристикой O(logN), или даже на дереве ван Эмде Боаса со сложностью O(log(logN)), но все алгоритмы с sublinear complexity не являются не алгоритмами обработки данных, а алгоритмами поиска.
Да, и не «вы» — система-то в общем не моя, я скорее сам критикую их архитектуру.
Вопрос не по теме. Вы практик или теоретик?
Генрих Форд придумал конвеер, тем самым повысив производительность труда на производстве.
Теперь дело за малым, повторно открыть гениальное открытие или сделать гениальное закрытие.
Получением исходных данных занимается один процесс. Второй, из переменной X не занимается тем же самым. Он делает совсем другую работу. И если эта работа требует больше затрат, читай тактов процессора, тогда можно организовать несколько потоков обработки данных от первого процесса.
Текстовые записи в журналах не однородны. Их так же можно разнести на группы обработчиков.
Получаем, что однородные данные будут обрабатываться за одинаковое количество шагов.
Поскольку данные не однородные, мы получаем разное количество шагов для каждой строки журнала.
Ваша математика рассыпалась на кучу условий если.
Скажу больше. Если в журнале все строки однородные, это уже не журнал, а суть поток однородных данных. И только в этом случае Ваши формулы становятся детерминированными и верными. И даже в этом случае можно применить конвеерную обработку данных.
Применение алгоритмов O(logN) на одном или нескольких участков конвеера даст прирост производительности. Вам понадобится гораздо меньшее количество процессов (автоматов) на этом участке. Высвободившийся ресурс можно задействовать на более тяжелом участке.
Решаем задачу Генриха Форда. Один мастер собирает 1 машину за 1 неделю. 50 мастеров за неделю соберут 50 машин. Маловато. Но для производства 100 машин надо построить еще один цех и нанять еще 50 мастеров. Продолжать?
Генрих Форд придумал конвеер, тем самым повысив производительность труда на производстве.
Теперь дело за малым, повторно открыть гениальное открытие или сделать гениальное закрытие.
Получением исходных данных занимается один процесс. Второй, из переменной X не занимается тем же самым. Он делает совсем другую работу. И если эта работа требует больше затрат, читай тактов процессора, тогда можно организовать несколько потоков обработки данных от первого процесса.
Текстовые записи в журналах не однородны. Их так же можно разнести на группы обработчиков.
Получаем, что однородные данные будут обрабатываться за одинаковое количество шагов.
Поскольку данные не однородные, мы получаем разное количество шагов для каждой строки журнала.
Ваша математика рассыпалась на кучу условий если.
Скажу больше. Если в журнале все строки однородные, это уже не журнал, а суть поток однородных данных. И только в этом случае Ваши формулы становятся детерминированными и верными. И даже в этом случае можно применить конвеерную обработку данных.
Применение алгоритмов O(logN) на одном или нескольких участков конвеера даст прирост производительности. Вам понадобится гораздо меньшее количество процессов (автоматов) на этом участке. Высвободившийся ресурс можно задействовать на более тяжелом участке.
Решаем задачу Генриха Форда. Один мастер собирает 1 машину за 1 неделю. 50 мастеров за неделю соберут 50 машин. Маловато. Но для производства 100 машин надо построить еще один цех и нанять еще 50 мастеров. Продолжать?
Тут похоже нужно пояснить не которые моменты, я вечером попробую расписать по подробнее
Общее впечатление от статьи: «Ребят, мы тут узнали, что существует NoSQL, и решили её внедрить! Но сейчас нам дальше рассказывать некогда, пора домашку делать.»
У комания AT Consulting есть подписанный договор NDA как исполнитель, который не позволяет детализировать все моменты. Если у вас есть конкретный вопрос, буду рад отвечать.
Почему SOAP, а не JSON?
SOAP являлся defacto стандартом для взаимодействия через СМЭВ с поставщиками услуг.
Кто решил, что для СМЭВ нужно использовать SOAP, и почему его, а не какой-нибудь другой протокол или формат обмена данными?
по приказу Министерства связи и массовых коммуникаций Российской Федерации от 27 декабря 2010 г. № 190 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия»
с приказом можно ознакомится по ссылке
smev.gosuslugi.ru/portal/api/files/get/424
с приказом можно ознакомится по ссылке
smev.gosuslugi.ru/portal/api/files/get/424
Ага, ясно, там люди до сих пор тексты в Lexicon for DOS набирают, видимо.
вы это зря )) у soap есть некоторые большие преимущества, это wsdl описания сервиса (которые еще применяется для создания stub) и валидация сообщения(я про wadl знаю) а также готовые разных стандартов от w3c и oasis. Такие стандарты очень важно для egovernance.
К wsdl-описаниям сервисов неплохо бы прилагать административный ресурс, который бы следил за тем, что (а) описания соответствуют сервисам и (б) в схеме сообщений в самом интересном месте не стоит
<xs:any/>. А то вроде и есть схема, а вроде и толку от нее ноль. А если учесть, что добрая половина данных в СМЭВ передавалась в виде вложений, то преимущества строгой типизации падали еще больше.>> Статья оставляет впечатление недосказанности:
Во-первых, зачем для сервиса накопления и анализа логов Cassandra?
За это ставят плюсы.
>> Линейная зависимость обработки данных от количества обрабатываемых данных, это главная проблема.
За это ставят минусы.
Ставьте еще.
Как только идет неудобная тема, сразу минус.
Мое мнение, попытка авторов проекта была интересная в плане самообучения. Но совсем провальная в плане производительности. Не удивлюсь, если следующая версия этой системы будет от другого производителя.
И честно, тут проблема не в том, используется ли реляционная база данных или нет.
Сумели переложить задачу с одной машины на несколько — «круто», «зачет», «так держать», «дай пять».
Производительность системы тает по линейному закону, а может, даже по экспоненте — полный провал.
Первый график после 57 идет вверх гораздо быстрее — плохо.
Второй график после 71 идет вверх гораздо быстрее — плохо.
Минусы надо ставить автору такой производительности, а не тому, кто вздумал критиковать.
Во-первых, зачем для сервиса накопления и анализа логов Cassandra?
За это ставят плюсы.
>> Линейная зависимость обработки данных от количества обрабатываемых данных, это главная проблема.
За это ставят минусы.
Ставьте еще.
Как только идет неудобная тема, сразу минус.
Мое мнение, попытка авторов проекта была интересная в плане самообучения. Но совсем провальная в плане производительности. Не удивлюсь, если следующая версия этой системы будет от другого производителя.
И честно, тут проблема не в том, используется ли реляционная база данных или нет.
Сумели переложить задачу с одной машины на несколько — «круто», «зачет», «так держать», «дай пять».
Производительность системы тает по линейному закону, а может, даже по экспоненте — полный провал.
Первый график после 57 идет вверх гораздо быстрее — плохо.
Второй график после 71 идет вверх гораздо быстрее — плохо.
Минусы надо ставить автору такой производительности, а не тому, кто вздумал критиковать.
Sign up to leave a comment.
Переход из SQL на NoSQL: опыт проекта СМЭВ 2.0