Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Хранение дерева в базе данных  (Прочитано 20382 раз)
0 Пользователей и 1 Гость смотрят эту тему.
baldr
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« : 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
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« Ответ #1 : 01-02-2011 09:09 » 

Забыл указать - размеры файлов - 10-40 Кб
Записан

Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 01-02-2011 09:39 » 

Что более накладно для базы?
Забыл указать - размеры файлов - 10-40 Кб

При таких объемах данных IMHO говорить о накладности не имеет смысла, не тот масштаб для базы данных.

Или есть какой-то более правильный способ?

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

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
baldr
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« Ответ #3 : 01-02-2011 09:57 » 

При таких объемах данных IMHO говорить о накладности не имеет смысла, не тот масштаб для базы данных.
Не вполне согласен. Имея INI-файл в 400 строк - получаем дерево с 400 нодами.
400*100=40000 записей для 100 серверов.
Еще есть XML с более сложной структурой (навскидку около 700 строк - минимум пара тысяч нод на файл).

Проще всего, конечно, грохать все дерево для каждого файла и пересоздавать заново.
Но как-то это не очень красиво что ли..
Записан

Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
Sla
Команда клуба

ua
Online Online
Пол: Мужской

WWW
« Ответ #4 : 01-02-2011 10:05 » 

тю... то ж немного

какой server  SQL?

для mysql можно посмотреть в сторону
http://dev.mysql.com/doc/refman/4.1/en/insert.html
INSERT ... ON DUPLICATE KEY UPDATE

или

http://dev.mysql.com/doc/refman/4.1/en/replace.html


Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Kivals
Команда клуба

ca
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 01-02-2011 10:10 » 

baldr, да - но задача будет распаралелена на 100 серверов, так что по сути загрузка минимальная. Ну а если ты обновление сделаешь не с одного сервера, а построишь сбалансированное дерево серверов - то все они вообще будут отдыхать Улыбаюсь
Я бы добавил к ноде время последнего обновления (заполняется автоматом: триггером on update).
Соответственно - выборка всех нод, у которых время изменения выше времени последнего обновления.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #6 : 01-02-2011 10:35 » 

Не вполне согласен. Имея INI-файл в 400 строк - получаем дерево с 400 нодами.
400*100=40000 записей для 100 серверов.

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

Проще всего, конечно, грохать все дерево для каждого файла и пересоздавать заново.
Но как-то это не очень красиво что ли..

Красив код, который прост и понятен. Если работает медленно - будем думать, как ускорить. Но это явно не тот случай.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
baldr
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« Ответ #7 : 01-02-2011 10:41 » 

Ок, всем спасибо, попробую тупо пересоздавать дерево - посмотрим что получится.
Записан

Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #8 : 01-02-2011 11:33 » 

За лимит времени в 5 минут даже на умеренно старой рабочей станции СУБД будет способна перелопатить порядка миллиона записей (если оперировать запросами, а не курсором). Тут масштаб на два порядка меньше, поэтому способ реализации - абсолютно любой, всё равной выйдет с изрядным запасом. Присоединяюсь к мнению, что в таких условиях лучше писать, как удобнее программисту.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
HandKot
Молодой специалист

ru
Offline Offline

« Ответ #9 : 02-02-2011 05:29 » 

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

скорость суля здесь уже не важна, так как пойдет парсинг файла
Записан

I Have Nine Lives You Have One Only
THINK!
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #10 : 02-02-2011 07:04 » 

HandKot, твоё предложение обходит сторой важный вопрос: насколько часто эти данные из базы нужны читателям. Убить дерево, и начать его создавать заново - это создать период времени, когда их в базе нету, в который кто-то может захотеть прочитать эти данные оттуда. И либо этот кто-то прочитает неполные данные, либо СУБД придётся нагрузить довольно тяжёлой (на 40 тыс. записей) транзакцией, суть которой сводится к тому, что СУБД сначала "в сторонке" сформирует новую базу, а потом быстренько перезапишет имеющуюся, заблокировав читателей на время перезаписи.

Убивать всё дерево можно в своей собственной программе, в которой эта операция синхронизирована с прочими (даже если данные хранятся в СУБД, просто база по сути однопользовательская), но это в высшей степени подозрительно делать в СУБД во многопользовательской базе, через которую пишущим и читающим клиентам сложно синхронизировать свои действия.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
HandKot
Молодой специалист

ru
Offline Offline

« Ответ #11 : 03-02-2011 10:32 » 

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

I Have Nine Lives You Have One Only
THINK!
baldr
Команда клуба

cy
Offline Offline
Пол: Мужской
Дорогие россияне


WWW
« Ответ #12 : 03-02-2011 12:07 » 

Решил реализовать полное сравнение деревьев и замену только изменившегося участка. Старая часть не удаляется, а верхняя изменившаяся нода помечается - получается заодно хранение истории изменений..
Что-то получилось, но еще не тестировал.. Улыбаюсь
Записан

Приличный компьютер всегда будет стоить дороже 1000 долларов, потому что 500 долларов - это не вполне прилично
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #13 : 03-02-2011 13:05 » 

HandKot, хоть целиком, хоть часть, хоть одну запись - всё едино. Вероятность ошибки чтения снижается, но достигает 0 только в том случае, когда так не делают.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
HandKot
Молодой специалист

ru
Offline Offline

« Ответ #14 : 04-02-2011 05:23 » 

ну уж лучше пользователь в блокировке повисит, чем получит "левые" данные и будет уверен, что они верны
хотя все зависит от задачи:
- и отчет строить без заблокированных записей
- и отчет строить на данных не завершенной транзакции
- и отчет строить на данных до обновления
Записан

I Have Nine Lives You Have One Only
THINK!
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines