|
|
|
|
|
Death_Master
|
 |
« Ответ #2 : 05 февраля 2007, 05:09:21 » |
|
Переформулирую: Можно ли загнать в БД весь кэш? Допустим, как 3-й вариант того, где хранить данные? P.S. А фрагментация меня не волнует, борюсь с ней успешно  |
|
|
|
|
|
|
Rick
|
|
« Ответ #3 : 05 февраля 2007, 05:13:37 » |
|
А в чем смысл предложения? И чем не устраивает виртуальный диск?
|
|
|
|
|
|
|
Death_Master
|
|
« Ответ #4 : 05 февраля 2007, 05:24:06 » |
|
Виртуальный диск таскает за собой лишний драйвер. 1. В БД средствами движка можно самостоятельно написать запрос по чистке ненужного 1.1. Или поиску нужного. 2. Индексирование присутствует в движке. 3. Можно будет сделать общую базу для нескольких компов (из нета каждый качает сам, а кэш общий(у каждого свой, но можно запросить у соседа). 4. Можно будет более четко отслеживать модификацию данных и обращения к ним. Чем плох такой вариант (в качестве дополнительного) ? |
|
|
|
|
|
|
Rick
|
|
« Ответ #5 : 05 февраля 2007, 05:41:13 » |
|
Виртуальный диск таскает за собой лишний драйвер.
А БД берется из воздуха? Вообще, как вариант, вполне имеет право на жизнь, но: Чем плох такой вариант (в качестве дополнительного) ? 1. Временными затратами на разработку (...шитья пойдет аршин - где деньги, Зин?). 2. Имхо хранить в БД большие файлы - плохая практика, а в кэше может оказаться все, что угодно. 3. Файловая система (без БД и виртуальных дисков) как правило быстрее. |
|
|
|
|
|
|
Death_Master
|
|
« Ответ #6 : 05 февраля 2007, 05:52:27 » |
|
0. БД конечно не из воздуха  , но драйвер выгрузить порой сложнее... 1. Может чем -нибудь помочь? : 2. Согласен, их можно и на диск 3. Но не всегда же? |
|
|
|
|
|
|
Rick
|
|
« Ответ #7 : 05 февраля 2007, 06:10:54 » |
|
1. Может чем -нибудь помочь? : Помощь всегда приветствуется. Желательно делом - т.е. если ты можешь предоставить _готовое_ решение (в виде dll, например), чтобы "прикрутка" к HC заключалась в добавлении "галочки" выбора способа хранения кэша - было бы хорошо. А там уж пользователь сам выберет как ему лучше. Не забыть про переход от одного способа хранения к другому и обратно. Ну, или спонсировать разработку. А "средние" варианты (какой из меня спонсор/готовое с потолка не падает - делать нужно) - надо обсуждать. Проще говоря, какую помощь ты можешь предложить? |
|
|
|
|
|
|
Death_Master
|
|
« Ответ #8 : 05 февраля 2007, 06:16:11 » |
|
Написать могу dll, если буду знать, какие функции нужны на экспорт, могу даже несколько dll написать, для разных типов баз.
Спонсировать пока не могу, сейчас на положении студента.....
|
|
|
|
|
|
|
Rick
|
|
« Ответ #9 : 05 февраля 2007, 06:29:07 » |
|
Написать могу dll, если буду знать, какие функции нужны на экспорт За конкретикой - к mai62. Но, в любом случае, прежде чем согласовывать взимодействие dll с HC нужно уже иметь какой-то "черновик". |
|
|
|
|
|
|
Сергей
|
|
« Ответ #10 : 05 февраля 2007, 10:50:52 » |
|
Виртуальный диск таскает за собой лишний драйвер.
А чем не устраивает выделенный раздел диска? |
|
|
|
|
|
Дем
Постоялец
Репутация: +6/-3
 Offline
Сообщений: 167
|
|
« Ответ #11 : 05 февраля 2007, 11:04:50 » |
|
Как мне кажется, надо подходить к делу разумно.
Если будет создана БД для хранения атрибутов - в ней имеет смысл хранить и мелкие файлы (<1-2-4К), коих и есть большинство. Накладные расходы при этом вырастут не сильно. А остальные - традиционно.
|
|
|
|
|
|
|
Death_Master
|
|
« Ответ #12 : 05 февраля 2007, 23:08:29 » |
|
А чем не устраивает выделенный раздел диска?
Переразбивкой, у меня напряжение скачет и иногда пропадает, а бесперебойник не справляется.... Как мне кажется, надо подходить к делу разумно.
Если будет создана БД для хранения атрибутов - в ней имеет смысл хранить и мелкие файлы (<1-2-4К), коих и есть большинство. Накладные расходы при этом вырастут не сильно. А остальные - традиционно.
Согласен, но тут доп. гемор при запросах на соседние кэши...... |
|
|
|
|
|
|
Сергей
|
|
« Ответ #13 : 06 февраля 2007, 17:04:16 » |
|
Переразбивкой, у меня напряжение скачет и иногда пропадает, а бесперебойник не справляется....
Процедура отрезания куска в конце диска обычно занимает несколько секунд. Поэтому вероятность запороть диск близка к нулю. Разумеется надо делать дефрагментацию заранее и бэкап не помешает. А база данных может легко сдохнуть при некорректном выключении компа. |
|
|
|
|
|
|
Death_Master
|
|
« Ответ #14 : 16 февраля 2007, 05:37:32 » |
|
Идея конечно не плоха, но я за кэш в БД целиком (для неск. пользователей)
|
|
|
|
|
|
NothingAnother
Beta tester
Репутация: +7/-2
Offline
Сообщений: 434
Spoiler
|
|
« Ответ #15 : 16 февраля 2007, 09:22:54 » |
|
я за кэш в БД целиком А при чём здесь индексирование?  |
Мы тоже не всего читали Шнитке!..
© В. Вишневский
|
|
|
|
|
Death_Master
|
|
« Ответ #16 : 16 февраля 2007, 14:29:09 » |
|
А при чём здесь индексирование? В БД есть собственный алгоритм индексирования. |
|
|
|
|
|
|
DenZzz
|
|
« Ответ #17 : 16 февраля 2007, 16:44:41 » |
|
Тема хранения кэша в базе данных уже как-то давно поднималась на ру-борде. Среди "плюсов" данного подхода: - БД позволяет организовывать конкурентный одновременный многопользовательский доступ;
- Быстрота обработки запросов, в т.ч. за счет внутреннего индексирования.
Среди "минусов":- Поддержка БД - вещь ресурсоёмкая - не факт, что на слабых машинках связка HC + БД не будет тяжеловесна...
- Проблемы с переносом кэша или его части на другие компы - требуются специальные процедуры экспорта, импорта и синхронизации.
- Трудности для любителей вручную поковыряться в кэше.
|
|
|
|
|
|
Дем
Постоялец
Репутация: +6/-3
Offline
Сообщений: 167
|
|
« Ответ #18 : 17 февраля 2007, 14:38:15 » |
|
1) Поддержка БД - вещь ресурсоёмкая - не факт, что на слабых машинках связка HC + БД не будет тяжеловесна...
2) Проблемы с переносом кэша или его части на другие компы - требуются специальные процедуры экспорта, импорта и синхронизации.
3) Трудности для любителей вручную поковыряться в кэше. 1) да, конечно. Хотя может скомпенсироваться отсутствием необходимости повторного прогона по регекспам (результат уже там) и т.п. 2,3) - зависит от выбора базы. зачастую можно перетащить сам файл базы... Ну и "копаться" - в базе зачастую удобней, чем в файловой системе |
|
|
|
|
|
|
DenZzz
|
|
« Ответ #19 : 18 февраля 2007, 21:28:04 » |
|
ДемХотя может скомпенсироваться отсутствием необходимости повторного прогона по регекспам (результат уже там) и т.п. Списки с регэкспами могли измениться с того времени! Следовательно, проверять их повторно все равно придется... зачастую можно перетащить сам файл базы... Вся БД может и не влезть на сменный носитель для ее переноса на другой комп! Следовательно, необходима специальная процедура выборочного экспорта/импорта БД.
|
|
|
|
|
|
|
