baldr
|
|
« : 01-02-2011 09:08 » |
|
Хочу посоветоваться по тому как правильно хранить данные в базе.. Есть несколько групп конфигурационных файлов разных типов - INI, XML и т.п. Файлов довольно много - 3-4 файла на каждом из 100 серверов. Данные в них могут незначительно меняться, скажем, несколько раз в день. Проверка на изменение производится с удаленного сервера раз в 5 минут. Нужно хранить данные из этих файлов, причем с возможностью быстро вытащить какое-то значение. На мой взгляд логично представить их в виде дерева нодами в виде записей nodeid-parentid-nodename-nodetype-nodevalue. Это позволит хранить как атрибуты, так и ветви. Но встает следующий вопрос - обновление. Допустим, у нас хранится в базе такое дерево - мы его распарсили и уже сохранили. Теперь мы имеем новый файл и знаем что в нем "что-то" поменялось - необходимо удалить старые ноды и добавить новые. Как правильнее поступить - убить все дерево и создать новое, либо искать по всему дереву и удалять/вставлять только изменения? В первом случае мы делаем только "delete from nodes where " по какому-либо простому условию и затем серия insert. Во втором случае мы бегаем по всему дереву, выполняя кучу select и сравнений, а затем delete/insert. Что более накладно для базы? Или есть какой-то более правильный способ?
|
|
|
Записан
|
Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
|
|
|
baldr
|
|
« Ответ #1 : 01-02-2011 09:09 » |
|
Забыл указать - размеры файлов - 10-40 Кб
|
|
|
Записан
|
Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
|
|
|
Dale
|
|
« Ответ #2 : 01-02-2011 09:39 » |
|
Что более накладно для базы? Забыл указать - размеры файлов - 10-40 Кб При таких объемах данных IMHO говорить о накладности не имеет смысла, не тот масштаб для базы данных. Или есть какой-то более правильный способ? Самый правильный способ - реализовать максимально просто и оптимизировать лишь при необходимости, когда это действительно нужно.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
baldr
|
|
« Ответ #3 : 01-02-2011 09:57 » |
|
При таких объемах данных IMHO говорить о накладности не имеет смысла, не тот масштаб для базы данных.
Не вполне согласен. Имея INI-файл в 400 строк - получаем дерево с 400 нодами. 400*100=40000 записей для 100 серверов. Еще есть XML с более сложной структурой (навскидку около 700 строк - минимум пара тысяч нод на файл). Проще всего, конечно, грохать все дерево для каждого файла и пересоздавать заново. Но как-то это не очень красиво что ли..
|
|
|
Записан
|
Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
|
|
|
|
Kivals
|
|
« Ответ #5 : 01-02-2011 10:10 » |
|
baldr, да - но задача будет распаралелена на 100 серверов, так что по сути загрузка минимальная. Ну а если ты обновление сделаешь не с одного сервера, а построишь сбалансированное дерево серверов - то все они вообще будут отдыхать Я бы добавил к ноде время последнего обновления (заполняется автоматом: триггером on update). Соответственно - выборка всех нод, у которых время изменения выше времени последнего обновления.
|
|
|
Записан
|
|
|
|
Dale
|
|
« Ответ #6 : 01-02-2011 10:35 » |
|
Не вполне согласен. Имея INI-файл в 400 строк - получаем дерево с 400 нодами. 400*100=40000 записей для 100 серверов. Поверьте, по меркам баз данных это совершенно смешные цифры. В моих базах живут миллиарды записей, и без особых напрягов. Проще всего, конечно, грохать все дерево для каждого файла и пересоздавать заново. Но как-то это не очень красиво что ли.. Красив код, который прост и понятен. Если работает медленно - будем думать, как ускорить. Но это явно не тот случай.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
baldr
|
|
« Ответ #7 : 01-02-2011 10:41 » |
|
Ок, всем спасибо, попробую тупо пересоздавать дерево - посмотрим что получится.
|
|
|
Записан
|
Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #8 : 01-02-2011 11:33 » |
|
За лимит времени в 5 минут даже на умеренно старой рабочей станции СУБД будет способна перелопатить порядка миллиона записей (если оперировать запросами, а не курсором). Тут масштаб на два порядка меньше, поэтому способ реализации - абсолютно любой, всё равной выйдет с изрядным запасом. Присоединяюсь к мнению, что в таких условиях лучше писать, как удобнее программисту.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
HandKot
Молодой специалист
Online
|
|
« Ответ #9 : 02-02-2011 05:29 » |
|
Допустим, у нас хранится в базе такое дерево - мы его распарсили и уже сохранили. Теперь мы имеем новый файл и знаем что в нем "что-то" поменялось - необходимо удалить старые ноды и добавить новые. ИМХО здесь ключевой момент если мы знаем то, что изменилось, тогда проще найти и заменить если мы не знаем, то, что изменилось тогда получаем парсинг файла по-любому, в этом случае проще убить все дерево и заново его прописать скорость суля здесь уже не важна, так как пойдет парсинг файла
|
|
|
Записан
|
I Have Nine Lives You Have One Only THINK!
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #10 : 02-02-2011 07:04 » |
|
HandKot, твоё предложение обходит сторой важный вопрос: насколько часто эти данные из базы нужны читателям. Убить дерево, и начать его создавать заново - это создать период времени, когда их в базе нету, в который кто-то может захотеть прочитать эти данные оттуда. И либо этот кто-то прочитает неполные данные, либо СУБД придётся нагрузить довольно тяжёлой (на 40 тыс. записей) транзакцией, суть которой сводится к тому, что СУБД сначала "в сторонке" сформирует новую базу, а потом быстренько перезапишет имеющуюся, заблокировав читателей на время перезаписи.
Убивать всё дерево можно в своей собственной программе, в которой эта операция синхронизирована с прочими (даже если данные хранятся в СУБД, просто база по сути однопользовательская), но это в высшей степени подозрительно делать в СУБД во многопользовательской базе, через которую пишущим и читающим клиентам сложно синхронизировать свои действия.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
HandKot
Молодой специалист
Online
|
|
« Ответ #11 : 03-02-2011 10:32 » |
|
я имел ввиду убивать ту часть дерева, которая относится именно к файлу, а размер фалй небольшой и отработает, даже при наложении блоктровки быстро
|
|
|
Записан
|
I Have Nine Lives You Have One Only THINK!
|
|
|
baldr
|
|
« Ответ #12 : 03-02-2011 12:07 » |
|
Решил реализовать полное сравнение деревьев и замену только изменившегося участка. Старая часть не удаляется, а верхняя изменившаяся нода помечается - получается заодно хранение истории изменений.. Что-то получилось, но еще не тестировал..
|
|
|
Записан
|
Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
|
|
|
Dimka
Деятель
Команда клуба
Offline
Пол:
|
|
« Ответ #13 : 03-02-2011 13:05 » |
|
HandKot, хоть целиком, хоть часть, хоть одну запись - всё едино. Вероятность ошибки чтения снижается, но достигает 0 только в том случае, когда так не делают.
|
|
|
Записан
|
Программировать - значит понимать (К. Нюгард) Невывернутое лучше, чем вправленное (М. Аврелий) Многие готовы скорее умереть, чем подумать (Б. Рассел)
|
|
|
HandKot
Молодой специалист
Online
|
|
« Ответ #14 : 04-02-2011 05:23 » |
|
ну уж лучше пользователь в блокировке повисит, чем получит "левые" данные и будет уверен, что они верны хотя все зависит от задачи: - и отчет строить без заблокированных записей - и отчет строить на данных не завершенной транзакции - и отчет строить на данных до обновления
|
|
|
Записан
|
I Have Nine Lives You Have One Only THINK!
|
|
|
|