Не упомянули что продукт OpenSource(с некоторыми ограничениями).
Давно пользуюсь данным тулом для прототипирования, как ML для домохозяек самое оно. Буквально нажал пару кнопок, получил модель, построил графики и работаешь.
Но делать пока что то серьезное на RapidMiner не удобно.
Спрос на вопросы может уменьшаться, по причине того, что поисковики развиваются и вопросы отлично гуглятся, при этом они уже задавались много раз.
Так же исследование не совсем репрезентативно, потому что не отражены технологии:
1. Имеющие тенденцию к росту
2. Имеющие стабильный спрос.
Интересный продукт, спасибо!
Подскажите, а Scrapinghub умеет работать с «динамическими» страницами с большим количеством JS? Например, ждать появления какого либо элемента страницы, прежде чем начать парсить страницу.
Спасибо за статью, а можно ли читать изменения из WAL? На одной из конференций я слышал про такую возможность стороннего плагина (берем из WAL и кладем в очередь), но что-то найти не могу.
Спасибо за статью, есть несколько вопросов:
1. Не совсем понятно, по какому механизму генерируются суррогатные ключи, и где хранятся натуральные?
2. Как и какими средствами документируете все это?
3. С каким проблемами приходится сталкиваться?
Похоже вы путаете «статистику» и «расследование фактов».
Идентификация базируется уже на каких то исследованных фактах, например, вы уже нашли мошенников и зафиксировали их. И далее:
1. скормили машине,
2. обучили ее,
3. она нашла кореляции фактов мошенничества с какими то другими показателями.
4. Применяете полученную модель для дальнейших поисков мошенничества.
Можно попробовать провести классификацию по общим признакам, но все равно, нужно расследовать, копать ручками по локоть.
Боюсь, что ваша задача не решается через чистый ML в текущей ее постановке.
Тем более на таком объеме данных и тем более на таком железе.
Вообще сравнивать скорость выполнения запросов в разных СУБД дело не благодарное — слишком много нюансов. Все аналитические СУБД обрабатывают данные примерно с одинаковой скоростью — все упирается в IO, CPU, алгоритмы компрессии данных, всякие фишки типа предрасчитанных агрегатов и т.д. Физику не обманешь, зато пнули пару рычажков или что-то недонастроили — БД уже тормозит.
Удивляют такие люди — «Настоящий кодер не будет читать Войну и Мир — настоящий кодер напишет ее с нуля».
Ну есть же достаточно большое количество СУБД которых вам с головой хватит, тем более при таких то объемах
Ручное кеширование можно прокачать, например забирать информацию из WAL.
Как-то на одной конфе по PG упоминалось расширение которое умеет читать WAL и класть информацию по изменениям в очереди. Дальше из этих очередей уже можно забирать и агрегировать данные. Конечно агрегат будет отставать от исходной таблицы.
К сожалению, не могу вспомнить название расширения.
Это конечно немного изврат, но в каких-то задачах пригодится.
Здравствуйте, сам давно вынашиваю подобную идею(частного города) и с большим удовольствием прочитал ваш пост.
Но есть несколько моментов:
1. Круговой город — это самая большая проблема современных городов, выросших из крепостей — Москва, Лондон и т.п. Круговая структура усложняет перемещение. Квадрат же дает больше путей для перемещения. Круговой город так же усложняет масштабируемость.
2. Большие парки — так же создают проблемы для перемещения из одного кластера у другой, что в сочетаниями с круговой структурой даст еще больше проблем чем есть в современных городах.
На мой взгляд идеально иметь квадратные микрорайоны и небольшие парки в шахматном порядке, либо парки внутри кварталов.
Насчет масштабирования города, город должен иметь определенные границы и не должен переростать их, если город достигает границ необходимо строить еще один город, но рядом, при этом обеспечивать скоростным общественным транспортом их сообщение.
Размеры города должны быть не большими(5-6 км), в идеале не требующими наличие автомобиля — все же на велосипеде или пешком передвигаться приятнее.
Кстати, слышали про «Venus project»? Тоже интересная концепция от одного достаточно известного инженера.
Еще можно по сигналу GPS определять что подходишь к дому и активировать режим «открывать всем».
Можно скомпилить OpenSource-версию(есть на гитхабе), позволяет обрабатывать больше 10к, но там нет некоторого полезного функционала.
Давно пользуюсь данным тулом для прототипирования, как ML для домохозяек самое оно. Буквально нажал пару кнопок, получил модель, построил графики и работаешь.
Но делать пока что то серьезное на RapidMiner не удобно.
Так же исследование не совсем репрезентативно, потому что не отражены технологии:
1. Имеющие тенденцию к росту
2. Имеющие стабильный спрос.
Не узнаю вас в гриме. :-)
Подскажите, а Scrapinghub умеет работать с «динамическими» страницами с большим количеством JS? Например, ждать появления какого либо элемента страницы, прежде чем начать парсить страницу.
https://github.com/michaelpq/pg_plugins/tree/master/decoder_raw — читает WAL и генерит SQL стейтменты
1. Не совсем понятно, по какому механизму генерируются суррогатные ключи, и где хранятся натуральные?
2. Как и какими средствами документируете все это?
3. С каким проблемами приходится сталкиваться?
Идентификация базируется уже на каких то исследованных фактах, например, вы уже нашли мошенников и зафиксировали их. И далее:
1. скормили машине,
2. обучили ее,
3. она нашла кореляции фактов мошенничества с какими то другими показателями.
4. Применяете полученную модель для дальнейших поисков мошенничества.
Можно попробовать провести классификацию по общим признакам, но все равно, нужно расследовать, копать ручками по локоть.
Боюсь, что ваша задача не решается через чистый ML в текущей ее постановке.
Вообще сравнивать скорость выполнения запросов в разных СУБД дело не благодарное — слишком много нюансов. Все аналитические СУБД обрабатывают данные примерно с одинаковой скоростью — все упирается в IO, CPU, алгоритмы компрессии данных, всякие фишки типа предрасчитанных агрегатов и т.д. Физику не обманешь, зато пнули пару рычажков или что-то недонастроили — БД уже тормозит.
Ну есть же достаточно большое количество СУБД которых вам с головой хватит, тем более при таких то объемах
А не замеряли нагрузку на CPU? Возможно ваши тесты ресурсоёмкие и упираются в процессор который и не дает нормально разогнаться IM
Как-то на одной конфе по PG упоминалось расширение которое умеет читать WAL и класть информацию по изменениям в очереди. Дальше из этих очередей уже можно забирать и агрегировать данные. Конечно агрегат будет отставать от исходной таблицы.
К сожалению, не могу вспомнить название расширения.
Это конечно немного изврат, но в каких-то задачах пригодится.
Но есть несколько моментов:
1. Круговой город — это самая большая проблема современных городов, выросших из крепостей — Москва, Лондон и т.п. Круговая структура усложняет перемещение. Квадрат же дает больше путей для перемещения. Круговой город так же усложняет масштабируемость.
2. Большие парки — так же создают проблемы для перемещения из одного кластера у другой, что в сочетаниями с круговой структурой даст еще больше проблем чем есть в современных городах.
На мой взгляд идеально иметь квадратные микрорайоны и небольшие парки в шахматном порядке, либо парки внутри кварталов.
Насчет масштабирования города, город должен иметь определенные границы и не должен переростать их, если город достигает границ необходимо строить еще один город, но рядом, при этом обеспечивать скоростным общественным транспортом их сообщение.
Размеры города должны быть не большими(5-6 км), в идеале не требующими наличие автомобиля — все же на велосипеде или пешком передвигаться приятнее.
Кстати, слышали про «Venus project»? Тоже интересная концепция от одного достаточно известного инженера.