Конкретно в нашем случае это самый лучший подход.
Отставание (которое составляет не больше 2-х минут) совсем не критично. Потеря данных нестрашна в силу того, что одни и те же данные как правило повторяются на нескольких серверах. А что касается нагрузки на диски, то даже для начального сервера записать файл размером 200-300 МБ в минуту и одновременно отдавать такой же файл за прошлую минуту — вообще не нагрузка с точки зрения IO (порядка 5% по iostat).
Хотя согласен, все зависит от задачи и для горячего онлайна, а тем более для транзакционных данных, такое решение не подойдет.
Сгодится. Правда придется приложение доработать.
У нас, например, есть 16 серверов, которые генерят данные. Делать инсерты сразу в БД мы перестали еще когда серверов было два.
В итоге сейчас данные пишутся локально на каждой машине в минутные файлы, там же локально обрабатываются если надо (cat, awk etc.) и потом льются в MySQL с помощью LOAD DATA INFILE на скорости до 10M записей в минуту.
Странно читать про низкую производительность.
У нас в проекте мы загружаем минутный лог, содержащий 4 млн. строк (файл 500 МБ) за 20 секунд используя LOAD DATA INFILE.
Уходит на это всего 20 секунд. Таким образом у нас производительность записи данных в MySQL составляет порядка 200 тыс строк в секунду.
Конечно, это просто загрузка лога, без какой-либо логики (IGNORE или UPDATE).
Дальнейшая логика обработки данных в MySQL тоже делается без труда — в нашем случае за счет быстрых MEMORY таблиц и правильного партицирования, которое распараллеливает задачу и ускоряет обработку в разы.
Критиковать и/или спорить про PG не собираюсь, ибо не знаю как. Все задачи, которые в проекте встречались, были успешно решены на MySQL, поэтому переезд на другую БД, например на PG, мы и не планировали.
Кто-нибудь скажите, а почему если TIMESTAMP это по сути юниксовое время (с 1970 года), то откуда MySQL берет значения '0000-00-00 00:00:00'.
Например вот выдержка из одной из моих таблиц:
Главное преимущество в том, что я и другие сотрудники достаточно глубоко знают MySQL. Это максимально ускоряет разработку, ибо не требует время на изучение, внедрение и поддержку новых технологий.
Я больше чем уверен, что многие разработчики просто ленятся глубоко копать SQL, а вместо этого, при первом же затыке бегут на Хабр читать что у нас там нового из NOSQL появилось (сам не раз спорил с сотрудниками по этому поводу).
Повторюсь, я не исключаю возможности использования каких-нибудь других решений. Просто пока задачи решаются на MySQL, они решаются на MySQL.
Есть лог событий, приходит на сервер в виде текстового файла длиной в минуту (порядка 6-9 млн записей). Лог содержит id юзеров, id событий, ip адреса, время и прочую информацию.
Загружаем данные в MySQL через LOAD DATA INFILE (самая быстрая операция в MySQL), по моим прикидкам предел для LOAD DATA INFILE где-то на уровне 40-50 млн. записей в минуту.
Потом удаляем дубликаты записей через INSERT IGNORE в MEMORY таблицу. Никакой движок на дисках не справиться с этим, проверено!
Собрав час бросаем таблицу на диски и дальше уже либо прямо тут делаем агрегацию (например подсчет юзеров на каждое событие), либо уносим на реплику и там делаем агрегацию.
Агрегированную информацию сохраняем в отдельные статичные таблицы, и уже с них работает frontend.
В общем у нас получилось наши задачи сделать на MySQL, но в реальности все конечно зависит от кейсов. Наверное есть такие задачи, которые в MySQL не сделать, но я пока не встречал. :-)
Мне тоже показалось, что до ограничений MySQL еще очень далеко.
У нас 100 млн. событий в час и мы (хоть и потратили на это пару человеко-месяцев) научились их обрабатывать в штатном MySQL.
Правильная структура данных + правильная агрегация под те или иные нужны творят чудеса!
Офигеть! 250 миллионов пользователей!!! Огромная армия.
А это всего пользователей или в онлайне? Это все торрент-клиенты или только официальные от Bittorent inc.?
У кого есть ссылка на исследование?
В контексте RTB есть очень интересная история противостояния Google и Facebook (фактически компаний, у которых есть свои RTB) с Microsoft, которая против вездесущего трекинга активности пользователей.
Microsoft за то, чтобы опция DNT (Do-Not-Track ) была включена в браузерах по умолчанию. А Google вообще против этой опции как таковой! www.xakep.ru/post/59124/default.asp
1. В новости, конечно, речь идет только о Франции. Но ведь и в Америке тоже и давно идут бесконечные судебные разбирательства между контент-провайдерами и операторами. Самая главная история вот: www.kipchatov.ru/blog/?p=668
В общем ничего страшного не вижу в этом. Просто бизнес ищет устраивающую всех конфигурацию рынка.
Не верю, что это может привести к исчезновению Интернета!
2. Концепция p2p начинает обретать новый смысл. Если трафик будет генерироваться не в огромных дата-центрах, подключенных к Интернету терабитными каналами, а будет генерировать миллионами маленьких узлов сети, то и места пиринговым войнам будет меньше. Ведь если пользователь внес абонентскую плату, то его трафик обеспечен полосой пропуская и вверх и вниз, какие могут быть споры?
1. Есть ли данные по количеству экранов?
Если количество экранов выросло на 6%, то общий рост за счет них и достигнут.
2. А есть ли подобны исследования по рынку DVD/BD?
Очевидно же, что распространяемые в период проката в торрентах экранки никак нельзя сравнивать с оригиналом по качеству! Так что потребление в торренах явно не коррелирует с потреблением на широком экране.
А вот с DVD и BD история кардинально другая — в торрнетах распространяется копия того же качества что и легальный диск.
Так что, мне кажется, по рынку DVD/BD должен наблюдаться спад.
Как-то не складывается картинка!
Как будто бы копирайт существует для поддержи низкокачественных американских продуктов.
Но я люблю смотреть голливудские фильмы (они самые качественные), покупаю немецкие автомобили и потребляю кучу других товаров совсем не американского производства/происхождения!
Похвально.
Но попытки эти у Bittorrent inc. уже были. Как минимум две. Обе безрезультатны.
Все-таки торренты = пиратство. Что ни говори, а именно так технология воспринимается большинством — и пользователями и мейджорами.
С трудом представляю как можно подвигнуть пиратов платить за легальный контент, если всегда есть бесплатная альтернатива, и порой даже лучшего качества чем оригинал.
Отставание (которое составляет не больше 2-х минут) совсем не критично. Потеря данных нестрашна в силу того, что одни и те же данные как правило повторяются на нескольких серверах. А что касается нагрузки на диски, то даже для начального сервера записать файл размером 200-300 МБ в минуту и одновременно отдавать такой же файл за прошлую минуту — вообще не нагрузка с точки зрения IO (порядка 5% по iostat).
Хотя согласен, все зависит от задачи и для горячего онлайна, а тем более для транзакционных данных, такое решение не подойдет.
У нас, например, есть 16 серверов, которые генерят данные. Делать инсерты сразу в БД мы перестали еще когда серверов было два.
В итоге сейчас данные пишутся локально на каждой машине в минутные файлы, там же локально обрабатываются если надо (cat, awk etc.) и потом льются в MySQL с помощью LOAD DATA INFILE на скорости до 10M записей в минуту.
Странно читать про низкую производительность.
У нас в проекте мы загружаем минутный лог, содержащий 4 млн. строк (файл 500 МБ) за 20 секунд используя LOAD DATA INFILE.
Уходит на это всего 20 секунд. Таким образом у нас производительность записи данных в MySQL составляет порядка 200 тыс строк в секунду.
Конечно, это просто загрузка лога, без какой-либо логики (IGNORE или UPDATE).
Дальнейшая логика обработки данных в MySQL тоже делается без труда — в нашем случае за счет быстрых MEMORY таблиц и правильного партицирования, которое распараллеливает задачу и ускоряет обработку в разы.
Критиковать и/или спорить про PG не собираюсь, ибо не знаю как. Все задачи, которые в проекте встречались, были успешно решены на MySQL, поэтому переезд на другую БД, например на PG, мы и не планировали.
Например вот выдержка из одной из моих таблиц:
first_seen timestamp DEFAULT '0000-00-00 00:00:00',
last_seen timestamp DEFAULT '0000-00-00 00:00:00',
И реально, SELECT дает значения '0000-00-00 00:00:00'.
Я больше чем уверен, что многие разработчики просто ленятся глубоко копать SQL, а вместо этого, при первом же затыке бегут на Хабр читать что у нас там нового из NOSQL появилось (сам не раз спорил с сотрудниками по этому поводу).
Повторюсь, я не исключаю возможности использования каких-нибудь других решений. Просто пока задачи решаются на MySQL, они решаются на MySQL.
Есть лог событий, приходит на сервер в виде текстового файла длиной в минуту (порядка 6-9 млн записей). Лог содержит id юзеров, id событий, ip адреса, время и прочую информацию.
Загружаем данные в MySQL через LOAD DATA INFILE (самая быстрая операция в MySQL), по моим прикидкам предел для LOAD DATA INFILE где-то на уровне 40-50 млн. записей в минуту.
Потом удаляем дубликаты записей через INSERT IGNORE в MEMORY таблицу. Никакой движок на дисках не справиться с этим, проверено!
Собрав час бросаем таблицу на диски и дальше уже либо прямо тут делаем агрегацию (например подсчет юзеров на каждое событие), либо уносим на реплику и там делаем агрегацию.
Агрегированную информацию сохраняем в отдельные статичные таблицы, и уже с них работает frontend.
В общем у нас получилось наши задачи сделать на MySQL, но в реальности все конечно зависит от кейсов. Наверное есть такие задачи, которые в MySQL не сделать, но я пока не встречал. :-)
У нас 100 млн. событий в час и мы (хоть и потратили на это пару человеко-месяцев) научились их обрабатывать в штатном MySQL.
Правильная структура данных + правильная агрегация под те или иные нужны творят чудеса!
Таки деньги государственные, ибо на 50% Ростелеком государственный.
А это всего пользователей или в онлайне? Это все торрент-клиенты или только официальные от Bittorent inc.?
У кого есть ссылка на исследование?
Или на этой высокоразвитой ИТ-планете не изобрели торрентов? =)
Microsoft за то, чтобы опция DNT (Do-Not-Track ) была включена в браузерах по умолчанию. А Google вообще против этой опции как таковой! www.xakep.ru/post/59124/default.asp
2. Федор Михайлович думает о России и nekaka Toix62AhSv.
3. Гаек: 2^1 маленьких + ~2^8 больших.
Чем не атака на ненавистный сервис?
1. В новости, конечно, речь идет только о Франции. Но ведь и в Америке тоже и давно идут бесконечные судебные разбирательства между контент-провайдерами и операторами. Самая главная история вот: www.kipchatov.ru/blog/?p=668
В общем ничего страшного не вижу в этом. Просто бизнес ищет устраивающую всех конфигурацию рынка.
Не верю, что это может привести к исчезновению Интернета!
2. Концепция p2p начинает обретать новый смысл. Если трафик будет генерироваться не в огромных дата-центрах, подключенных к Интернету терабитными каналами, а будет генерировать миллионами маленьких узлов сети, то и места пиринговым войнам будет меньше. Ведь если пользователь внес абонентскую плату, то его трафик обеспечен полосой пропуская и вверх и вниз, какие могут быть споры?
1. Есть ли данные по количеству экранов?
Если количество экранов выросло на 6%, то общий рост за счет них и достигнут.
2. А есть ли подобны исследования по рынку DVD/BD?
Очевидно же, что распространяемые в период проката в торрентах экранки никак нельзя сравнивать с оригиналом по качеству! Так что потребление в торренах явно не коррелирует с потреблением на широком экране.
А вот с DVD и BD история кардинально другая — в торрнетах распространяется копия того же качества что и легальный диск.
Так что, мне кажется, по рынку DVD/BD должен наблюдаться спад.
Как будто бы копирайт существует для поддержи низкокачественных американских продуктов.
Но я люблю смотреть голливудские фильмы (они самые качественные), покупаю немецкие автомобили и потребляю кучу других товаров совсем не американского производства/происхождения!
Но попытки эти у Bittorrent inc. уже были. Как минимум две. Обе безрезультатны.
Все-таки торренты = пиратство. Что ни говори, а именно так технология воспринимается большинством — и пользователями и мейджорами.
С трудом представляю как можно подвигнуть пиратов платить за легальный контент, если всегда есть бесплатная альтернатива, и порой даже лучшего качества чем оригинал.