Грамотная организация хранения большого обьема данных.

Может кто уже сталкивался с таким вопросом:
Нужно грамотно организовать и работу со следующей структурой данных:

Есть поисковик. Нужно сохранить кейворды, но так что бы можно было получить данные за любой промежуток времени с точностью до часа.

Я вижу только возможностью хранения в файлах со следующей структурой:
На каждый день создавать файлы вида:
T 01 02 03 04 ...
Query1_amount amount,a_amount,xdate
Qeury2_amount
....
Где строки - это запросы, а столбцы время. И первый столбец - итоговое значение за день данного кейводра (по сути сумма остальных столбцов). Таким образом при запросе за конкретный день - статсы сразу будут найдены. Но проиводительность будет существенно падать с увеличением диапозона.

Придется с каждого файла считывать запрос и итоговое значение и затем суммировать все эти массивы за каждй день. А если к примеру 100.000 запросов в день и нужны статсы за год - придется совместить 360 массивов с десятком тысяч строк в каждом! Хранить данные в одном месте (в мускуле к примеру) - еще хуже - будет таблица в 3.600.000 за год к примеру, а если нужны данные за месяц, да и вообще такую таблицу обработать как-то напряжно будет... ;) ? Тож получается плохо... я лучшего варианта чем хранение данные в файле
с вышеприведенно структурой не вижу... но ведь способ то должен быть Мож кто подкинет идейку?

А почему MySQL не хочешь использовать?

Ну... во первых это я в качестве примера привел. На самом деле таких файлов очень много, и инфы в них тоже очень много... Сдается мне мускуль такого нахальства не выдержит...

Да и не хочется этого делать, в базе - те параметры которые нужны для постоянной работы, а это - нужно будет время от времени, т.е. держать такие обьемы редко используемой инфы в базе бессмысленно. Да и файлы хоть зипнуть можно И обработать с удаленных компов легче... в общем причин достаточно

MySQL хранит таблицы в виде файлов, так что если создавать по таблице на каждый день (неделю или месяц) то получим то же самое, что тебе нужно + оптимизация запросов, таблиц, бэкап, архивация и др. возможности мускуля.

Цитата:

01 02 03 04

еще один очевидный плюс: в мускуле эта строка (столбец) займет 4 байта (по байту на час), а в файле 12 (2 цифры+пробел на час)

но если хочешь свою СУБД написать - попробуй :-)

Цитата:

Хранить данные в одном месте (в мускуле к примеру) - еще хуже - будет таблица в 3.600.000 за год к примеру, а если нужны данные за месяц, да и вообще такую таблицу обработать как-то напряжно будет

У меня база icq номеров (номер - примари мыло) занимала свыше 10 миллионов записей. Найти нужный номерок составляло около секунды. Никаких притензий к такому колличеству записей мускуль не имел
Имхо для обработки большого колличества записей лучше базы ничего нет.

Foxtrot писал:

MySQL хранит таблицы в виде файлов, так что если создавать по таблице на каждый день (неделю или месяц) то получим то же самое, что тебе нужно + оптимизация запросов, таблиц, бэкап, архивация и др. возможности мускуля. еще один очевидный плюс: в мускуле эта строка (столбец) займет 4 байта (по байту на час), а в файле 12 (2 цифры+пробел на час) но если хочешь свою СУБД написать - попробуй :-)

хз.. может ты и прав... но все равно не лежит душа держать такие объемы данных в мускуле... Да и еще один плюс в пользу файлов в том, что мускуль постоянно будет занят другими, более важными делами, не хочется его грузить еще и этим... Да и как-то проще с файлами работать, хоть разнести их можно по директориям, потом с других компов можно легко забрать обработать...

Да и вопрос кстати не в этом же был Пускай даже и мускуль использовать, это не настолько важно, - но как так данные в приведенном примере сгруппировать, что бы не положить сервак при хитро-мудром запросе?

[DEL]

Последний раз редактировалось: KVS Support (01/07/17 в 10:33), всего редактировалось 1 раз

Ну коли MySQL не хочешь (а следовало бы, только использовать таблицы InnoDB вместо MyISAM), то можешь попробовать SleepyCat Berkeley DB 4 (dba_open). Это сверхбыстрый бинарный формат файлов типа ключ->значение (в твоем случае киворд -> количество).

правда делать выборку напряжнее конечно. да юзай InnoDB-таблицы.

Pentarh писал:

да юзай InnoDB-таблицы.

А чем они в двух словах лучше MyISAM?
И не ляжет ли MySQL при добавлении скажем ~20 таблиц в день с ~3 млн. записей (суммарно в них всех) в день? Т.е. к примеру через год будет уже 7200 таблиц и 1 млрд. записей в них...

Сколько вообще мускуль способен выдержать?
Может у кого есть какие либо реальные данные по скорости работы, обработки инфы на мускуле?

Какие минусы использования большого числа таблиц в мускуле? (помимо того что через webadmin не посмотришь ;) )

P.S. Многие партнерки предоставлют подобную статистику - не уж то у них все в мускуле храниться?

Спасибо за ответы.

Цитата:

А если база в 1 млрд строк? И выборка более сложная?

А ты думаешь хранить такие данные в файлах и делать по ним сложные выборки тебе будет проще ? Здгавствуйте изобретатели велосипедов

Если вас смущает мускуль, ставьте оракл, на соответствующем железе он столько потянет без проблем.
Нет денег - вперед на изучение и тесты мускуля с merge таблицами.

P.S. сначала 3,5 миллиона записей в год, потом уже миллиард Стоит все таки определится .

Stek писал:

А ты думаешь хранить такие данные в файлах и делать по ним сложные выборки тебе будет проще ? Здгавствуйте изобретатели велосипедов

На файлах мне проше организовать эту структуру и проще ею управлять, время запросов меня волновало только в одном случае - приведенном выше.

Stek писал:

Если вас смущает мускуль, ставьте оракл, на соответствующем железе он столько потянет без проблем.

Ну... оракт - это уже несколько другой уровень во всех отношениях.

Stek писал:

P.S. сначала 3,5 миллиона записей в год, потом уже миллиард Стоит все таки определится .

Вначале я привел пример а затем уже более реальные данные.

А как с надежностью в мускуле при работе с такими обьемами?

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

для данной задачи майСКЛ действительно лучше чем флатфайлы.
1. быстрее обрабатыватся данные будут.
2. меньше ресурсов жрется в итоге.

а если все таки через файлы делать, то будь готов что при больших обьемах данных придется строить промежуточные индексы или построковую обработку файлов.

еще мануал по AWK рекомендую глянуть, для работы с файловыми базами полезная штука.

Цитата:

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

Сэр, решение вашей задачи вам вряд ли тут будут разжевывать. Сказанно было уже предостаточно. Есть база, есть документация, тестовый скрипт пишется за 5 минут, миллиард данных в таблицу загоняется за пару часов.

А потом определись блин с задачей, то три лимона записей, то миллиард, то сложная их выборка, то архивация.

Kernel Team, а зачем вообще такая статистика тебе? В ней обязательная необходимость?

PS. У мускля ограничение на объём индексов 4Гб.

Для таких задач наиболее эффективно писать отдельную не-SQL базу, иначе с какого-то момента будет сильный пролет по скорости либо по ресурсам, а скорее всего - и по тому и по другому одновременно.
Но перед написанием - четко понять все-таки что надо получить в итоге, потому что "универсально" не получится, чем-то придется жертвовать.

Ну и иметь представление, на каком железе это будет исполняться (главным образом - объем доступной оперативки)

насчет "и параллельно сервак постоянно занят" - такие задачи обычно требуют отдельного сервера, т.е. она хорошо работает, если ее "не отвлекают".

Про файлы забудь как страшный сон. Дружеский совет.
Мускль можешь попробовать, если 100% представляешь себе как он внутрях работает и сможешь диагностировать и скорректировать затык в случае чего, а не просто констатировать "епть, вот и мускль лег". Я когда аналогичную задачу решал, не был в себе настолько уверен, и пробовать мускль не стал, потому что при неправильном подходе это будет жопа.
Можно беркли попробовать, но он не всегда отвечает задачам, хотя если отвечает - то работает шустро.

В общем, большие объемы данных - это отдельная песня, ее с кондачка не решишь.

Ну либо действительно ораклы всякие, если денег дохуя

Кстати беркли довольно гибкая и шустрая штука, но пхпшный интерфейс (Database dbm-style Abstraction Layer Functions) не оставил от фич BerkeleyDB и четвертой части. На берклях работают спутниковые, навигационные, коммуникационные и прочие объемные и ответственные программные решения. И объем баз зачастую исчисляется терабайтами.

Более мощный интерфейс к BerkeleyDB имхо в перле

Спасибо всем за ответы, за представленные идеи, теперь есть достаточно путей куда можно копать дальше.

Будем считать топик закрытым.