|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Пожалуй, я-таки проголосовал бы за DB2 Express-C (не знаю насчёт PostgreSQL, слышал только нехорошее слово "vacuum"). Надо бы только оценить, важно ли ограничение в 2 гига ОЗУ, что зависит от объёма запрашиваемых данных и случайности запросов этих данных. Для быстрого удаления имеет смысл применять "партишионирование для бедных" - т.е. разбить данные на несколько таблиц и поверх них сделать view с union all; drop'ать/пересоздавать таблицы и view, когда данные в таблицах устарели. (Интересно, что лицензия запрещает использовать MDC (многомерные кластера) и компрессию на Express-C, но физически они, вроде бы, не были отключены. А это чрезвычайно удобные и полезные штуки). Насколько я вижу по синтаксису CREATE TABLE в DB2 9.7 (сам не пробовал создавать), таблица может принадлежать нескольким tablespace (раньше такого не было). Таким образом, имеет смысл создать по одному tablespace на каждый диск и бекапить по-тэйблспэйсно, а таблицы создавать на всех "данновых" tablespace сразу. Размер страницы имеет смысл выбрать в 32K (как известно, основное время тратится на позиционирование, а не на считывание); если оставить дефолтный, без толку пропадёт море места. Так называемый blob определить как VARCHAR(1024) FOR BIT DATA. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2011, 00:48 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Victor MetelitsaНасколько я вижу по синтаксису CREATE TABLE в DB2 9.7 (сам не пробовал создавать), таблица может принадлежать нескольким tablespace (раньше такого не было). Таким образом, имеет смысл создать по одному tablespace на каждый диск и бекапить по-тэйблспэйсно, а таблицы создавать на всех "данновых" tablespace сразу. Это что за чудо такое? Чтобы тейблспейс состоял из нескольких файлов, такое понятно. Но чтобы таблица лежала сразу на нескольких тейблспейсах, вы не путаете это с париционированием? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2011, 01:32 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.sql.ref.doc/doc/r0000927.html Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2011, 08:48 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Не претендую на "серебрянную пулю", но почему просто не попробовать несколько вариантов? Например, на MSSQL 2008R2 это будет выглядеть примерно так: сжатая секционированная таблица с кластерным индексом по полям поиска. В случае удаления "100 млн" - просто выкидываем секцию из таблицы. Это происходит на уровне метаданных, и выполняется микросекунды. В одном из моих проектов была таблица, содержащая примерно 5 млрд записей (подневные остатки крупной торговой сети), система очень хорошо себя чувствовала на машине, которая даже не поддерживала х64 (сервер был родом из начала века). Дисковая подсистема была приблизительно того же уровня. Правда, там не было блобов, но тут только тест все покажет. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.08.2011, 22:47 |
|
выбор БД для хранения 8Tb данных
|
|||
---|---|---|---|
#18+
Да. DB2 очень хорошая СУБД. Я знаю много больших баз данных на ней. И быстро и надежно. Не встречал проблем с ней. CACHE тоже может подойти. Но я был свидетелем когда при внезапном отключении электричества база CACHE испортилась(база теневого копирования), а вот с DB2 таких случаев не припомню. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2011, 11:37 |
|
|
start [/forum/topic.php?fid=35&msg=37372051&tid=1552625]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 146ms |
0 / 0 |