Лог в виде БД
google: sqlite 10 millions records - отвечает, что при правильном использовании работает нормально
Berkeley DB, быстрее вряд ли что найдёшь
Во время удаления старых записей база будет недоступна на запись, так что если серверу не позволено подолгу тормозить, то будет плохо. Так что правильнее из сервера вести текстовые логи, а в базу их накатывать по крону раз в минуту.
А типа просто переименовать файл с базой, чтоб новый создался, не покатит?
Лог часом не от исы?
Это что-то типа сервера, регистрирующего и соединяющего друг с другом клиентов. Закладываемая макс нагрузка - 1000 соединений в секунду, то есть по 1000 записей в лог в секунду где-то по 16-20 байт на запись. То есть в сутки речь идет о примерно сотне миллионов записей.
Так а за какой макс промежуток будет храниться хистори? День? Месяц?
1-2 дня, потом в архив
Тада норм. Ротировать по методу 'а, а выборку прогонять на сротированной уже базе, в которую ничего не пишется.
Покатит, но ведь БД нужна, насколько я понял, чтобы всякие group by и where за последние N часов делать, придется часть логики реализовывать руками.
Перечитал изначальную формулировку, ну да, можно просто анализировать лог сразу после ротации.
А типа просто переименовать файл с базой, чтоб новый создался, не покатит?Не покатит.
Логи писать в текстовый файл, идиотизмом не заниматься. Логи ротировать, старые логи парсить и отвечать на вопросы по ним.
Если вопросы фиксированы, то зачем нужна БД ваще непонятно.
SQL.
Если вопросы фиксированыНет
При этом, учитывая то, что формальные требования по логике работы будут добавляться, есть ненулевая вероятность, что часть вопросов надо будет задавать не разово и не после ротации. Мигрировать с sqlite на другую субд будет проще чем с текстовых логов.
НетПросто "нет" мало. Например, твои проблемы вполне может решать grep | sort | uniq | tail | head | wc.
При этом, учитывая то, что формальные требования по логике работы будут добавляться, есть ненулевая вероятность, что часть вопросов надо будет задавать не разово и не после ротации.
Нет. Если у тебя достаточно быстро собираются логи, то в нормальной системе нигде не может быть такого жесткого требования ко времени обработки одной записи (т.к. обрабатывается в пачке с другими либо надо настроить фильтр и обрабатывать правильно потоком (при получении, например, а не после sql-запроса).
Мигрировать с sqlite на другую субд будет проще чем с текстовых логов.
Зачем?
Если ротировать БД — уже придется как-то заниматься несколькими БД например, мержить, или задавать sql-вопросы к нескольким БД одновременно а тебе данные больше чем за 2 дня не нужны.
Переписать скриптик парсинга логов в другую СУБД очень просто (если вообще нужно будет что-либо менять для использования другой СУБД).
Если ты думаешь что мигрировать с sqlite легко — погугли чуток на эту тему.
Итого: "ты не должен этого хотеть", по крайней мере пока по описанию задачи получается так.
---
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Просто "нет" мало. Например, твои проблемы вполне может решать grep | sort | uniq | tail | head | wc.Нет - это, к сожалению, именно нет. Проект в зародыше и может меняться в зависимости от направления развития, как и этот инструмент.
И даже если эти фильтры позволят реализовать требуемое, то чем это лучше SQL? Еще неизвестно кто быстрее обработает и какой запрос будет проще написать.
Нет. Если у тебя достаточно быстро собираются логи, то в нормальной системе нигде не может быть такого жесткого требования ко времени обработки одной записи (т.к. обрабатывается в пачке с другими либо надо настроить фильтр и обрабатывать правильно потоком (при получении, например, а не после sql-запроса).Значит, это "ненормальная система" (всегда радуюсь такой категоричности). Пре-обработка/кэш - это вопрос оптимизации. И к вопросу сейчас не относится. Я держу в голове варианты развития, но реализовывать их сразу не вижу смысла (да и никто не даст ресурсов).
Итого: "ты не должен этого хотеть", по крайней мере пока по описанию задачи получается так.
Мне это неочевидно. Преимуществ работы с текстовыми логами я пока не вижу.
И даже если эти фильтры позволят реализовать требуемое, то чем это лучше SQL? Еще неизвестно кто быстрее обработает и какой запрос будет проще написать.Если ты заранее правильные индексы заранее создашь, то SQL быстро обработает. А для этого нужно знать, какие запросы будут.
А перегенерировать индексы может быть дольше, чем текст переобработать.
Преимуществ работы с текстовыми логами я пока не вижу.tail -f собственно - основное преимущество
Если ты заранее правильные индексы заранее создашь, то SQL быстро обработает. А для этого нужно знать, какие запросы будут.Ну да, совершенно непонятно, что лучше. Я об этом и говорю.
А перегенерировать индексы может быть дольше, чем текст переобработать.
ЗЫ Я _не_ сторонник SQL, но я при этом и _не_ фанат тратить доп ресурсы на реализацию велосипеда.
А типа просто переименовать файл с базой, чтоб новый создался, не покатит?Если уж речь идёт об использовании DBMS, то лучше переименовывать таблицы. В большинстве случаев это практически моментальная операция. В том числе это решает проблему миграции на другую базу (где не получится переименовать файл).
Нет - это, к сожалению, именно нет. Проект в зародыше и может меняться в зависимости от направления развития, как и этот инструмент.Поэтому ты этот инструмент уже сейчас закладываешь на использование sqlite или подобий? Твой инструмент уже не сможет сильно меняться.
Давай простой пример:
Ротируем БД с access-логами раз в сутки. Тебе нужно получить всех линуксоидов за вчера и позавчера. Как будешь решать?
И даже если эти фильтры позволят реализовать требуемое, то чем это лучше SQL? Еще неизвестно кто быстрее обработает и какой запрос будет проще написать.
У тебя есть поток данных, который ты собираешь через окошко шириной в сутки (например а смотришь на него через окошко шириной в двое суток (например). Расскажи, sql предназначен для этого?
Значит, это "ненормальная система" (всегда радуюсь такой категоричности).
Я тоже очень радуюсь, поскольку вариант "это ненормальный архитектор" почему-то никто рассмотреть не хочет
Я держу в голове варианты развития, но реализовывать их сразу не вижу смысла (да и никто не даст ресурсов).
Извини, но ты _уже_ собрался делать штуку (тратить ресурсы которая решает задачи, решенные на уровне системы (ротация и хранение логов не понимая зачем тебе это надо вообще.
Поэтому ты этот инструмент уже сейчас закладываешь на использование sqlite или подобий? Твой инструмент уже не сможет сильно меняться.
Я закладываюсь на sql, потому что это дает на данный момент больше свободы в развитии/миграции функционала (то есть выборки данных). Потому что меняться будут условия регистрации или условия создания соединения клиентов или добавление доп методов работы с клиентом.
Давай простой пример:Ты не уточнил время ротации. Если твой вопрос про запрос к нескольким бд, то я и сделаю по запросу к каждой бд (выбирая всех клиентов в нужном промежутке времени с полем ось линукс зная какие времена хранит какая бд (по именам файлов/бд или же по доп информации откуда-то). После чего объединю. Если все лежит в одной бд, вопроса нет. Если вопрос про механизм ротации, то я пока думаю, как это делать.
Ротируем БД с access-логами раз в сутки. Тебе нужно получить всех линуксоидов за вчера и позавчера. Как будешь решать?
У тебя есть поток данных, который ты собираешь через окошко шириной в сутки (например а смотришь на него через окошко шириной в двое суток (например). Расскажи, sql предназначен для этого?
Вопрос не понял, честно говоря. SQL/парсинг инструментарий не имеет никакого отношения к ротации и источникам данных, нет?
Я тоже очень радуюсь, поскольку вариант "это ненормальный архитектор" почему-то никто рассмотреть не хочет
Уточню, объявление чего-то ненормальным без должного обоснования. Я частенько ошибаюсь и прекрасно осведомлен об этом. Да и не стал бы обсуждать что-то, будь иначе, не? )
Извини, но ты _уже_ собрался делать штуку (тратить ресурсы которая решает задачи, решенные на уровне системы (ротация и хранение логов не понимая зачем тебе это надо вообще.
Сейчас стоит задача собрать максимум информации, так как очень мало известно из того, что именно потребуется вытаскивать. Почему мое решение нелогично? Я обезопасился со стороны удобства и гибкости выборки данных, реализован относительно константную работу по ротации и хранению. Ты мне предлагаешь меньше думать о возможностях по выборке, так как по твоим представлениям, там не может быть ничего из того, что не даст выполнить парсинг текста (например по скорости выборки) и просто выбрать удобное средство хранения.
ЗЫ Про динамическое тз беседовать неинтересно, тут я подневолен, и это бессмысленно.
Извини, но ты _уже_ собрался делать штуку (тратить ресурсы которая решает задачи, решенные на уровне системы (ротация и хранение логов)А о каком решении идет речь?
А о каком решении идет речь?Почему сначала спросил про logrotate, а потом застеснялся?
Вот, например, гугл сказал: http://sial.org/howto/logging/rotate/ — тут есть много названий утилит которые так или иначе делают ротацию логов.
Я закладываюсь на sql, потому что это дает на данный момент больше свободы в развитии/миграции функционала (то есть выборки данных). Потому что меняться будут условия регистрации или условия создания соединения клиентов или добавление доп методов работы с клиентом.SQL нужен для _реляционных_ БД, а не для хранения одной большой таблички. Ты же начнешь использовать БД, влезешь в проблемы с ротацией, синхронизацией, скоростью и локами. На пустом месте.
Ты не уточнил время ротации. Если твой вопрос про запрос к нескольким бд, то я и сделаю по запросу к каждой бд (выбирая всех клиентов в нужном промежутке времени с полем ось линукс зная какие времена хранит какая бд (по именам файлов/бд или же по доп информации откуда-то). После чего объединю. Если все лежит в одной бд, вопроса нет. Если вопрос про механизм ротации, то я пока думаю, как это делать.
Вопрос про то как весело будет возиться с несколькими БД, да, вместо одного grep.
Вопрос не понял, честно говоря. SQL/парсинг инструментарий не имеет никакого отношения к ротации и источникам данных, нет?
Именно. Так нафиг тебе нужен sql если все что тебе сейчас надо — хранить логи?
Сейчас стоит задача собрать максимум информации, так как очень мало известно из того, что именно потребуется вытаскивать. Почему мое решение нелогично? Я обезопасился со стороны удобства и гибкости выборки данных, реализован относительно константную работу по ротации и хранению. Ты мне предлагаешь меньше думать о возможностях по выборке, так как по твоим представлениям, там не может быть ничего из того, что не даст выполнить парсинг текста (например по скорости выборки) и просто выбрать удобное средство хранения.
ЗЫ Про динамическое тз беседовать неинтересно, тут я подневолен, и это бессмысленно.
Повторюсь: вся инфа есть в логах и отлично собирается. Нужно просто почитать маны про grep & sort.
Обезопасился ты с той стороны, с которой тебе это пока не нужно.
Про динамическое ТЗ беседовать смысл есть, поскольку тут как раз тот случай, что человек придумывает как бы ему поинтереснее поиграть с программками, делая то что сейчас никому не надо.
Я тебе говорю что все вкусности SQL — в реляционности. А у тебя всего одна табличка с логами, и запросы к одной табличке будут примитивны.
Ты микроскопом гвозди забивать пытаешься, причем интересуешься "хватит ли микроскопа на миллион гвоздей".
Сдохнет ли такая бд уже на вторые сутки по сравнению с нормальной субд типа мускула?А зачем логи писать в БД? Это же очевидно, что заведомо не будет работать.
Я бы даже не то что в БД, даже на диск не писал бы.
Я бы даже не то что в БД, даже на диск не писал бы.Для этого надо представлять какие данные из логов и в какой момент нужны.
Я сейчас подробно опишу что и как я вижу, и дальше сам думай.
Первое, что ты точно должен решить — насколько эта информация для тебя важна. Проеб логов за пол дня — это неприятность, большая неприятность или "хрен с ними уже через час"?
Второе: обрабатывать лучше сразу, используя "коридор" для небольшой очереди. Такой коридор лучше всего организовывать в шареной памяти, тогда один демон пишет, а другой разгребает. Обычно хватает коридора на 2-4 часа работы, дальше в случае чего переподнимут.
Обрабатывать лучше сразу ещё и потому, что это вообще не грузит диск, и при желании достигается эффект реального времени. Зачем делать запись+чтение, когда можно сразу посчитать нужное?
Это что касается обсчета. Что касается хранения: я всегда пишут текстовый лог, но на лету пакую в gz. Это сильно разгружает диск, а преимущества текстового лога очевидны: cat/grep/cut/sed/awk.
Если данные некритичные (логи очередного говна, которые потом годами никому не нужны пока винт не выкинут) — я бы даже не писал и на диск. А зачем? Прошлогодний снег обычно неинтересен никому. Если что надо обсчитывать — просто делай это в реальном времени, бэкап — только если данные важные и могут потребоваться, например, для расследования.
Первое, что ты точно должен решить — насколько эта информация для тебя важна. Проеб логов за пол дня — это неприятность, большая неприятность или "хрен с ними уже через час"?
Второе: обрабатывать лучше сразу, используя "коридор" для небольшой очереди. Такой коридор лучше всего организовывать в шареной памяти, тогда один демон пишет, а другой разгребает. Обычно хватает коридора на 2-4 часа работы, дальше в случае чего переподнимут.
Обрабатывать лучше сразу ещё и потому, что это вообще не грузит диск, и при желании достигается эффект реального времени. Зачем делать запись+чтение, когда можно сразу посчитать нужное?
Это что касается обсчета. Что касается хранения: я всегда пишут текстовый лог, но на лету пакую в gz. Это сильно разгружает диск, а преимущества текстового лога очевидны: cat/grep/cut/sed/awk.
Если данные некритичные (логи очередного говна, которые потом годами никому не нужны пока винт не выкинут) — я бы даже не писал и на диск. А зачем? Прошлогодний снег обычно неинтересен никому. Если что надо обсчитывать — просто делай это в реальном времени, бэкап — только если данные важные и могут потребоваться, например, для расследования.
Для этого надо представлять какие данные из логов и в какой момент нужны.Чаще всего можно всё на лету пересчитать, а логи только тормозят основную систему.
Как пример приведу top.mail.ru. Логов никаких, всё считается сразу, бэкап не делается. Зачем, когда всё равно никто не будет пересчитывать сраные счетчик за прошлогоднее 1 апреля?
Как пример приведу top.mail.ru. Логов никаких, всё считается сразу, бэкап не делается. Зачем, когда всё равно никто не будет пересчитывать сраные счетчик за прошлогоднее 1 апреля?Ну вот а я знаю интересное применение этим логам, то есть они мне были бы полезны. Думаю что считаете вы оттуда не все что хочется знать мне.
SQL нужен для _реляционных_ БД, а не для хранения одной большой таблички. Ты же начнешь использовать БД, влезешь в проблемы с ротацией, синхронизацией, скоростью и локами. На пустом месте.Ну, таблиц, не далее как сегодня, уже стало две, но одна по рамерам на порядки меньше другой. Это запросы клиентов на баны других клиентов, если нужна конкретика. И между ними уже маячит призрак связи через клиентов
Проблемы с синхронизацией, скоростью и локами сейчас не стоят, а когда начнутся, что, инструментарий по работе с текстовыми логами сможет обойтись без них?
Повторюсь: вся инфа есть в логах и отлично собирается
Инфа отлично собирается, но уже не дает возможности работать в рантайме по причине текстового парсинга. Я, как бы, все про то же соотношение преимуществ/недостатков
В общем, спасибо всем за обсуждение!
Ну вот а я знаю интересное применение этим логам, то есть они мне были бы полезны. Думаю что считаете вы оттуда не все что хочется знать мне.Во-первых, я уже в Мыле не работаю, во-вторых — очевидно считается меньше.
Хочется считать больше — считай сам. Топ Мыла вообще ориентирован считать минимум. До меня в 2005 он вообще был на одной машине, я хоть разнес на несколько, кластеризовал. Сейчас по-моему машин 10.
Если считать больше, то парк машин надо увеличивать.
Проблемы с синхронизацией, скоростью и локами сейчас не стоят, а когда начнутся, что, инструментарий по работе с текстовыми логами сможет обойтись без них?Если нет проблем со скоростью, то ты или в Газпроме, или там вообще данных кот наплакал как мало.
Спасибо, подумаю!
Если нет проблем со скоростью, то ты или в Газпроме, или там вообще данных кот наплакал как мало.Ключевое слово _сейчас_
> А перегенерировать индексы может быть дольше, чем текст переобработать.
Опыт показывает, что это неправда.
---
...Я работаю антинаучным аферистом...
Опыт показывает, что это неправда.
---
...Я работаю антинаучным аферистом...
Ну, таблиц, не далее как сегодня, уже стало две, но одна по рамерам на порядки меньше другой. Это запросы клиентов на баны других клиентов, если нужна конкретика. И между ними уже маячит призрак связи через клиентовИ ты собираешься сюда писать лог в реальном времени?
Ну удачи, чо Спасибо за обсуждение
> В случае текстовых файлов я ручками делаю _не_ меньше.
> А по ощущениям, больше. Я, конечно, могу ошибаться.
Ты прав, и если будут предлагать BDB и прочий "nosql," шли к чёрту,
значительно проще создать пару десятков индексов, чем правильно
переписать забитые запросы.
Если данных мало, они все поместятся в памяти, если много ---
понадобится настоящая DBMS, это тоже надо учитывать.
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
> А по ощущениям, больше. Я, конечно, могу ошибаться.
Ты прав, и если будут предлагать BDB и прочий "nosql," шли к чёрту,
значительно проще создать пару десятков индексов, чем правильно
переписать забитые запросы.
Если данных мало, они все поместятся в памяти, если много ---
понадобится настоящая DBMS, это тоже надо учитывать.
---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."
Если данных мало, они все поместятся в памяти, если много ---А если потом потребуется OLAP, то не будет пользы от этих индексов - всё равно структуру нужно будет переделывать.
понадобится настоящая DBMS, это тоже надо учитывать.
Просто "нет" мало. Например, твои проблемы вполне может решать grep | sort | uniq | tail | head | wc.это подразумевает, что любой запрос будет O(n хотя для db с индексом можно иметь запросы в том числе и O(log n)
это подразумевает, что любой запрос будет O(nпри чем не просто O(кол-ва записей а O(от длины всего файла)
это подразумевает, что любой запрос будет O(n хотя для db с индексом можно иметь запросы в том числе и O(log n)Ты придумал "зачем"?
Ты придумал "зачем"?сколько раз заходили на страницу логин.
сколько страниц обрабатывались больше, чем 0.5с
сколько раз заходили на страницу логин.Не "зачем задавать вопросы?", а "зачем получать ответы за O(log n)?" .
сколько страниц обрабатывались больше, чем 0.5с
Не "зачем задавать вопросы?", а "зачем получать ответы за O(log n)?" .чтобы меньше компьютеров надо было покупать под эту байдовину
зы
кстати group by с последующей агрегацией как реализовывается через *nix-овые команды?
чтобы меньше компьютеров надо было покупать под эту байдовинуПрограммисты дешевле железа? Ты в Индии?
Не очень понял связь времени и количества железа, кстати.
кстати group by с последующей агрегацией как реализовывается через *nix-овые команды?
uniq -c
uniq -cа агреграция в виде sum-ы как потом прикручивается?
Программисты дешевле железа? Ты в Индии?но уж написать sql-запрос явно стоит дешевле, чем тоже самое через комбинацию nix-овый команд
но уж написать sql-запрос явно стоит дешевле, чем тоже самое через комбинацию nix-овый командКак посчитал?
Так и почему чтобы быстро посчитать ответ на вопрос надо меньше машин?
Где рассказ про критичность O(log n)?
а агреграция в виде sum-ы как потом прикручивается?
http://unstableme.blogspot.com/2008/09/sum-of-and-group-by-u...
http://unstableme.blogspot.com/2008/09/sum-of-and-group-by-u...т.е. только через awk?
+ пианисту и _n0_. Логи писать и хранить гзипованым текстом, если очень хочется - генерить аггрегаты по ним и писать в базу (опционально, если очень хочется sql).
Просто, надежно, отлично скалируется, очень гибко
Просто, надежно, отлично скалируется, очень гибко
Если данных мало, они все поместятся в памяти, если много ---Если данных много, они тоже поместятся в памяти, только памяти нужно тоже много.
понадобится настоящая DBMS, это тоже надо учитывать.
Неужели нет ни одной свободной базы данных типа kdb+? Она бы идеально подошла под требования, но лицензия очень дорогая.
kdb+ тут — это из пушки по воробьям имхо...
т.е. только через awk?Диалог о скорости свелся к обсуждению "зы"?
Напоминаю:
чтобы меньше компьютеров надо было покупать под эту байдовину
зы
кстати group by с последующей агрегацией как реализовывается через *nix-овые команды?
Диалог о скорости свелся к обсуждению "зы"?мне непонятно что обсуждать.
инструменты выбираются на основе следующих критериев (порядок приоритетов расставляется от контекста):
скорость(себестоимость) разработки,
гибкость/полнота,
скорость выполнения,
стоимость сопровождения/эксплуатации (зависимость от окружения).
имхо,
sql разрабатывать быстрее,
на ряде задач(за небольшим исключением) он бегает быстрее, чем последовательность linux-овых команд,
по гибкости сравнимы (на ряде задач гибче одно, на других другое
у sql-я зависимость от окружения много меньше
Ничем не могу помочь, ты первый стал рассказывать про O(log n).вот именно поэтому мне и не понятно, что обсуждать, т.к. непонятно что именно ты отрицаешь.
при обработке логов есть задачи вида:
O(log кол-во записей)
O(кол-во записей)
O(размер лога)
O(кол-во записей * log кол-во записей)
для sql они решаются с той же оценкой, причем последняя задача может решаться(выборка) за O(кол-во записей) при наличие правильного индекса.
на файлах все тоже самое решается(кроме последнего) за O(C*размера лога)
итого: по критерию производительность - при наличие большого числа задач - sql выигрывает у решения, через nix-овые команды.
вот именно поэтому мне и не понятно, что обсуждать, т.к. непонятно что именно ты отрицаешь.У тебя проблемы с чтением? Напоминаю:
Как посчитал?
Так и почему чтобы быстро посчитать ответ на вопрос надо меньше машин?
Где рассказ про критичность O(log n)?
Где я что-то отрицаю?
> Как посчитал?
что именно?, почему задача со сложностью O(log n) для nix-овый команд имеет сложность O(C*размер файла)?
> Так и почему чтобы быстро посчитать ответ на вопрос надо меньше машин?
есть две задачи: одна O(n) другая O(log n) - для sql они решаются за то же время, для файлов - за O(размер файла)
итого, через sql нагрузка в два раза меньше, значит вместо одной машины достаточно будет полмашины.
> Где рассказ про критичность O(log n)?
не критично, но приятно.
при этом ты не привел примеры задач, когда nix-овые команды будут бегать быстрее, чем sql.
что именно?, почему задача со сложностью O(log n) для nix-овый команд имеет сложность O(C*размер файла)?
> Так и почему чтобы быстро посчитать ответ на вопрос надо меньше машин?
есть две задачи: одна O(n) другая O(log n) - для sql они решаются за то же время, для файлов - за O(размер файла)
итого, через sql нагрузка в два раза меньше, значит вместо одной машины достаточно будет полмашины.
> Где рассказ про критичность O(log n)?
не критично, но приятно.
при этом ты не привел примеры задач, когда nix-овые команды будут бегать быстрее, чем sql.
> Где рассказ про критичность O(log n)?Ок, вот на этом месте обсуждение про О(log n) предлагается закончить, потому как такая асимптотика никому не нужна.
не критично, но приятно.
при этом ты не привел примеры задач, когда nix-овые команды будут бегать быстрее, чем sql.
Где я что-то отрицаю?
Не очень понял связь времени и количества железа, кстати.вроде, очевидно - что чем задача жрет меньше ресурсов, то тем меньше ресурсов нужно для выполнения задачи.
машина является ресурсом.
вроде, очевидно - что чем задача жрет меньше ресурсов, то тем меньше ресурсов нужно для выполнения задачи.Ну дык я так понимаю ты сначала говорил про время ( O(log n) vs O(n) ) а не про количество ресурсов?
машина является ресурсом.
Ну дык я так понимаю ты сначала говорил про время ( O(log n) vs O(n) ) а не про количество ресурсов?если задача выполняется за x-времени, то и ресурсов она жрет x.
если, конечно, туда зачем-то sleep-ов не наставляли.
если задача выполняется за x-времени, то и ресурсов она жрет x.Могу выполнить задачку за время 2t на одной машине или на 2-х машинах за время t.
Время разное, ресурсы одинаковые?
Могу выполнить задачку за время 2t на одной машине или на 2-х машинах за время t.некорректный пример.
Время разное, ресурсы одинаковые?
утверждения всегда исходят из контекста "при прочих равных".
некорректный пример.O(log n) и O(n) занимают одинаковое количество памяти, ядер, тактов? Или просто у тебя удобные абстракции?
утверждения всегда исходят из контекста "при прочих равных".
Ну хорошо:
Могу выполнить задачку за время 2t на одном ядре или на 2-х ядрах за время t. При прочих равных. Время разное, ресурсы одинаковые?
Могу выполнить задачку за время 2t на одном ядре или на 2-х ядрах за время t. При прочих равных. Время разное, ресурсы одинаковые?ты бы еще привел ситуацию с двумя разными процессорами: один медленный, другой быстрый...
зы
прочие - разные, в одном случае ресурс(процессор) используется один, в другой - два.
для уравнивания: либо переходится к времени суммарной загрузки ресурсов, либо вводится еще один критерий: что одни задачи или инструменты лучше паралеллятся, а другие хуже.
ты бы еще привел ситуацию с двумя разными процессорами: один медленный, другой быстрый...Я-то при чем? Ты стал рассказывать что железа для SQL надо меньше потому что он быстрее.
А я только рассказал что
1) логика эта неправильная.
2) ты не учитываешь "ресурсы" на возню с БД (то что БД надо готовить, а логи сами в файлик пишутся)
3) характер вопросов к данным неизвестен
4) время ответа на вопросы никого не волнует.
На этом дискуссию, по-моему, можно прекратить, чтобы не зацикливать тред. Ну или можно начать читать его с начала.
с базой гемора на порядок больше при таких масштабах данных. raw данные туда класть это бред. Как минимум из-за проблем с ротацией. Пусть у тебя есть запрос, который выдает тебе какие-то данные за день. Как его модифицировать для выдачи результата за месяц? Для файлов это подача на вход более длинного списка файлов и пойти поспать. Для базы гемора явно больше.
Был у меня как-то проект, где надо было хранить 150М записей в таблице (почасовые данные за три месяца). Запросы к базе были разные, создано было 5-6 индексов. В один прекрасный день индекс не влез в 16 гигов памяти. Кончилось все хорошо, но затрахался я капитально, там еще переезжать на другой бокс надо было и обычный mysqldump работал несколько часов. Расширение на большее число боксов тоже гемор жуткий был бы, но в данном проекте хотя бы необходимость во всем этом была, так как запросы adhoc и ответы должны были быть в реальном времени.
Такой гемор себе на жопу иметь ни за что это крайняя степень мазохизма имхо.
Был у меня как-то проект, где надо было хранить 150М записей в таблице (почасовые данные за три месяца). Запросы к базе были разные, создано было 5-6 индексов. В один прекрасный день индекс не влез в 16 гигов памяти. Кончилось все хорошо, но затрахался я капитально, там еще переезжать на другой бокс надо было и обычный mysqldump работал несколько часов. Расширение на большее число боксов тоже гемор жуткий был бы, но в данном проекте хотя бы необходимость во всем этом была, так как запросы adhoc и ответы должны были быть в реальном времени.
Такой гемор себе на жопу иметь ни за что это крайняя степень мазохизма имхо.
Для файлов это подача на вход более длинного списка файлов и пойти поспать. Для базы гемора явно больше.Если в базе есть подзапросы и union, то примерно столько же.
2) ты не учитываешь "ресурсы" на возню с БД (то что БД надо готовить, а логи сами в файлик пишутся)ресурсы можно и без кавычек написать, так как вставка в БД, особенно с индексами, очевидно дороже добавления строчки в файл
а никому не приходило в голову, что конвертить сначала из программного представления в человеко читаемое (логи) чтобы потом его мучительно конвертить обратно (греп, демон, етц) это не совсем айс?
почему бы вместо логов не реализовать некий механизм уведомлений (для джавы это может быть к примеру jms pub-sub) через который программа в программном представлении будет жаловаться на жизнь, а обработчики этого дела уже будут думать что делать - перегружать сервера, форматировать диск или звонить хозяину ...
почему бы вместо логов не реализовать некий механизм уведомлений (для джавы это может быть к примеру jms pub-sub) через который программа в программном представлении будет жаловаться на жизнь, а обработчики этого дела уже будут думать что делать - перегружать сервера, форматировать диск или звонить хозяину ...
Оставить комментарий
tipnote
Однопроцессный сервер пишет информационный лог. Например по гигабайту в сутки. Ежедневно разово из лога извлекаются несколькими запросами некоторые данные. Запросы простые. Схема лога простая. Хочется использовать под это дело что-нибудь быстрое и встраиваемое типа sqlite. Типа ротация организуется просто, ресурсы не жрет и так далее.Сдохнет ли такая бд уже на вторые сутки по сравнению с нормальной субд типа мускула?