Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
Carrie
Есть postgresql 7.4.x, есть таблица, в которой кол-во записей ~35млн, одно из полей типа SMALLINT (2bytes) и по нему создан Btree индекс.
так вот запрос вида
select count(*) from tbl_name where это_поле>17::smallint;
выполняется ~40секунд при том что результат запроса - всего 9003 записей.
Explain показывает, что БД юзает индекс.
Так же тестировался mysql 4.0.18, где результаты существенно печальней. Конфиги для mysql и postgresql, как мне кажется, настроены сейчас оптимально; машинка с БД более чем приличная (2x2.4 Xeon, 2Гб RAM, 4x36Гб SCSI etc..)


Интересно. Запрос по индексу и 40 секунд на такой машине? Что то мне про mysql не верится. Что за таблицы - innodb? myisam? и что говорит

mysqladmin ext var

после запроса? и какой explain? И как цеплялись про тестровании? tcp/ip? unix socket? И что говорит

vmstat

во время запроса? (может вы перестарались с памятью и у вас все в swap пошло)
27 авг 04, 23:38    [915787]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
2Злой.

Для описанной здесь задачи. Преимущества Oracle c версионностью нивелируются тем что данные не меняются. Они сняты с сетевых устройств и менять их смысла нет. По поводу грубой силы в Teradata, там тоже есть аналоги Materialized Views и др. С другой стороны ныличие большого кол-ва возможностей усложняет написание хорошего оптимизатора ибо нужно разрабатывать огромное кол-во алгоритмов которые корректно будуи учитывать все эти возможности. Так что богатый набор возможностей не всегда хорошо.
28 авг 04, 13:18    [916036]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
В данной конкретной задаче. Предположим что имеется пара запросов, таких что данные вставка которых происходит удовлетворяет предикату в where. Имеем конфликт читателей с писателями. В случае если СУБД блокировщик, или кто-то дрыхнет на блокировке, пока данные загружаются, или мы имеем non-repeatable read. То есть запустив 2 запроса подряд мы можем иметь данные которые не согласуются друг с другом. Что приводит к нецензурным восклицаниям и вырыванию остатков волосяного покрова при попытке отладки такой системы. Несогласованное чтение - это плохо. Можно этот недостаток СУБД-блокировщика учесть и компенсировать при разработке приложения. А можно использовать СУБД-версионник, свободную от данного недостатка, и бороться с ее недостатками (В случае Оракла - snapshot too old error). ИМХО второе - проще и дешевле, ибо вопрос решается покупкой железяки.
30 авг 04, 07:56    [916792]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Зл0й

А можно использовать СУБД-версионник, свободную от данного недостатка, и бороться с ее недостатками (В случае Оракла - snapshot too old error). ИМХО второе - проще и дешевле, ибо вопрос решается покупкой железяки.


Если я правильно понимаю то начиная с версии 9i уже бороться не надо.
Просто правильно подобрать Retention_time и не скупиться на диски.
30 авг 04, 10:54    [917191]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Если я правильно понимаю то начиная с версии 9i уже бороться не надо.
Просто правильно подобрать Retention_time и не скупиться на диски.


Точнее, начиная с 9.2.0.4 В некоторых случаях по прежнему приходится делать "ручками", но все реже и реже.
31 авг 04, 01:15    [919880]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Зл0й
Если я правильно понимаю то начиная с версии 9i уже бороться не надо.
Просто правильно подобрать Retention_time и не скупиться на диски.


Точнее, начиная с 9.2.0.4 В некоторых случаях по прежнему приходится делать "ручками", но все реже и реже.


Мы только с 9.2.0.4 стали серьезно смотреть на 9i.
Уж больно много багов.
Реалии времени, пока не выйдет второй релиз не пользовать.

Можно как-то намекнуть, что именно надо делать ручками,
именно для сегментов отката
при установленном параметре UNDO_MANAGEMENT = AUTO?
31 авг 04, 10:26    [920326]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Carrie
Member

Откуда:
Сообщений: 17
Прошу прощения, что надолго пропал, но тут и без меня дискуссия уже развернулась неплохо)

LeXa NalBat
1)
автор
CREATE INDEX traffic_history_idx2 ON traffic_history (ip, id); //нужен для JOIN'а
Здесь наверное опечатка. Вы имели в виду индекс traffic_history (ip, blob_ref)?

Да, конечно.

LeXa NalBat

2)
Чем в этом запросе индекс blobs (ts_stop, id) может быть полезнее индекса blobs (ts_stop)? Ведь по первому аргументу ts_stop ограничение на интервал, а не на равенство.

Индексы
CREATE INDEX traffic_history_idx2 ON traffic_history (ip, blob_ref);
CREATE INDEX blobs_idx2 ON blobs (ts_stop, id);
просто создал на всякий случай, чтобы посмотреть какие из них postgres будет использовать. И как выяснилось, часто (всегда) postgres использует индекс blobs_idx2, но никогда traffic_history_idx2 или просто blobs_idx1.

LeXa NalBat
3)
Какие проблемы с этим запросом в постгресе? :-) Какой план выполнения или скорость вы хотели бы иметь?

План запроса меня устраивает. меня не устраивает скорость его выполнения: 30-40сек. Хотелось бы не более 5сек. Мне почему-то кажется, что пробежаться по индексу по записям число которых 10-20к - это должно быть быстро.

LeXa NalBat
4)
Я не силен в теории, но чем-то эта задача мне напоминает OLAP. Может быть вам посмотреть в эту сторону? (Не обязательно на MS-OLAP или оракловый, я не так давно сваял что-то похожее на коленке на постгресе - в процессе массированной загрузки данных вычисляются всевозможные агрегаты, которые впоследствии используются при показе статистики.)

Вариант, конечно. И я про него помню, но не люблю избыточность в БД даже в таком виде, вероятно, из-за малого опыта) Конечно, все равно придется ее использовать, вопрос только где и когда.

Nikolay Kulikov
Произвоидельность тупого индекс скана зависит от подсистемы IO.
Что у вас c ней??? Опять же попробуй указывать >, a >=
Потому как > 17 и 18, и 19, и 20 etc...
A если укажешь >=18 то серверу будет понятно с какой ветки индекса начинать скан.

Про > и >= не знал, спасибо.
С производительностью машины судя, по простым тестам, все нормально, конфиги postgres'а похоже оптимальны. По крайней мере изменение многих параметров не отражается значительно на производительности. Своппинга тоже нет, так что с shared_buffers, effective_cache_size не перестарался.
Хотя все же несколько смущает то, что в тесте создания таблицы, предложенного LeXa NalBat, разница в 2.5 раза :(

Что касается CLUSTER. Попробовал. Результаты - супер: все указанные запросы выполняются "махом" (<1сек). Жалко не часто эту команду можно запускать: на таблице traffic_history с 20млн записей по индексу на поле ip она выполняется почти 1.5часа) Кстати, после этого (и ес-но ANALYZE) оба multicolumn-индекса постгрес перестал использовать.
Partition tables "руками" делать не хочется: сложно с этим работать потом. Вычитал, что базы вроде Oracle и etc умеют это прозрачно. Здорово. Был бы опыт или знакомый знаток Oracle - попробовал бы эту фичу. Сам лезть пока не решаюсь.

Читаю статьи по тюнингу postgres'а еще раз, запущу еще раз тесты на другой тестовой машинке, уровнем пониже (есть все же сомнения в скорости IO), почитаю по MDC.
31 авг 04, 10:55    [920451]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Carrie
Member

Откуда:
Сообщений: 17
Хрен
Интересно. Запрос по индексу и 40 секунд на такой машине? Что то мне про mysql не верится. Что за таблицы - innodb? myisam? и что говорит

mysqladmin ext var

после запроса? и какой explain? И как цеплялись про тестровании? tcp/ip? unix socket? И что говорит

vmstat

во время запроса? (может вы перестарались с памятью и у вас все в swap пошло)

Использовал только innodb, т.к. хочется транзакций и без них страшно. Цеплялся через локально через unix socket, правда какая тут разница? результат-то маленький. Машинка не свопилась 100%
Вообще как выяснилось на запросе вида SELECT COUNT(*) FROM ... где WHERE только по индексу, mysql не обращается к данным таблицы и выполняет его очень быстро. Но ведь реально мне нужно не настолько простой запрос, который уже "лезет" в таблицу и это получается в 3-4 раза медленнее, чем в постгресе Протестить еще раз сложно, да и не хотелось бы на mysql обращать внимание: не нравится он мне стабильностью.
31 авг 04, 11:01    [920481]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
автор
Протестить еще раз сложно, да и не хотелось бы на mysql обращать внимание:


Ага, вот с этого надо было начинать. Тогда конечно mysql снимается с повески дня (все остальное - решаемо)

автор
не нравится он мне стабильностью.


Ха-ха.. хорошо звучит.
31 авг 04, 13:03    [921100]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Carrie
Member

Откуда:
Сообщений: 17
Хрен
Ага, вот с этого надо было начинать. Тогда конечно mysql снимается с повески дня (все остальное - решаемо)

Настроен mysql-сервер был идеально (этим занимался человек, который общался с ним далеко не в первый раз). Данные в таблицу были залиты те же самые. Сервак был со 100% idle. Запрос вида select count(*), sum(cost) from tbl1 where pr>17 занял более 2-х минут.
31 авг 04, 14:09    [921496]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
Carrie
(этим занимался человек, который общался с ним далеко не в первый раз).


Ха-ха... хорошая формулировка :-) вы сегодня поддерживаете мое хорошее настроение. Если серьезно - то эти 2 минуты и говорят о том насколько "идеальна" была настройка. На самом деле под mysql используютсяя _очень_ большие базы.
31 авг 04, 14:33    [921622]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Carrie
Member

Откуда:
Сообщений: 17
Насколько большие базы? размер/кол-во таблиц?

Ок. Вы меня убедили попробовать mysql ещё раз.
31 авг 04, 14:43    [921688]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Матаня
Guest
При солидных объемах базы запросы с агрегатными функциями
у Постгреса выполняются достаточно долго - и галочки "турбо_count"
пока что не существует. 8-) Подробно обэтом написано где-то здесь....

инфа о настройке Постгреса

Мне кажется нужно сначала хорошенько продумать
организацию базы.
А вообще-то многое можно сказать еще про обдуманность вопроса
и ответов...только влом.
Может кто-то подскажет, почему эта ветка
вызывает у меня ассоциаци с вопросом о числе ангелов
топчущихся на кончике иглы? 8-)

P.S Пишите письма машииным кодом.
3 сен 04, 23:37    [934791]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Матаня
Guest
При солидных объемах базы запросы с агрегатными функциями
у Постгреса выполняются достаточно долго - и галочки "турбо_count"
пока что не существует. 8-) Подробно обэтом написано где-то здесь....

инфа о настройке Постгреса

Мне кажется нужно сначала хорошенько продумать
организацию базы.
А вообще-то многое можно сказать еще про обдуманность вопроса
и ответов...только влом.
Может кто-то подскажет, почему эта ветка
вызывает у меня ассоциаци с вопросом о числе ангелов
топчущихся на кончике иглы? 8-)

P.S Пишите письма мЫшинНым кодом.
3 сен 04, 23:38    [934792]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Случайно заглянул
Guest
Зл0й
Oracle - версионник. Соотвественно пока объемов Rollback Segment'ов хватает, вы можете одновременно писать и читать одну и ту же таблицу в разных сессиях. Без взаимных блокировок и грязного чтения. Этим Оракл выгодно отличается от Teradata и DB2. Поясню примером

<момент времени>. <событие>

T1. Сессия S1 начала читать здоровенную таблицу my_table
T2. Сессия S2 изменила запись номер 123,456,789 еще не прочитанную сессией S1
Т3. Сессия S1 дошла до записи номер 123,456,789 и обнаружила что запись была изменена в момент времени Т2 > T1. Поскольку Оракл обязан выдать данные по состоянию на Т1, он залезет в rollback segment и разыщет там старое значение записи номер 123,456,789 на момент времени Т1. Это значение и будет использовано запросом из сессии S1.

Естественно "панацеи на бывает". Допустим в момент времени Т2 сессия S2 не только изменила запись, но и прибила ее с помощью commit. Тогда тогда место в rollback segment где лежит старое значение записи номер 123,456,789 на момент времени Т1, будет помечено как "available for reuse". Если в момент времени Т3 сессия S1 обнаружит что нужные ей данные отсутствуют (поверх них уже записали что-то другое) то она выдаст ошибку ORA-1555 Snapshot too old. Поэтому в системе где загрузка происходит одновременно с запросами требуется иметь rollback segment'ы соотвествующего размера.


Как красиво :) easy way. Купил базу и на коленке слабал продукт.

Представим бухгалтерию сесия (сеcсия S2) дебитует счет,
При этом сесия S1 дебитует тот-же счет.
То есть получится, Если сумма по транзакциям S1+S2 больше остатка на счете, одна из них должна отклониться по недостатку средств. Но этого
не произойдет. И окончательное значение остатка не будет учитывать
транзакцию которая завершилась раньше.
А потом еще вы очень долго будете искать откуда у вас касса(склад)
разезжаются с бухгалтерией.
Описанный вами пример - часный случай грязного чтения.

Oracle кстате версиониик только внешне, внутри он все такой же блокировочник.
ИХМО постоянное возникновенни ошибки ORA-1555 Snapshot too old
коственно говорит о кривости рук проектировщика базы.

Зл0й

В СУБД-блокировщиках (Teradata, DB2, Sybase, Informix) нам приходится выбирать между грязным чтением и ожиданием на блокировке. Выбор из "двух зол" и весьма неприятный. Я уж лучше прикуплю отдельный дисковый массив и целенаправленно забабахаю туда свои rollback segment'ы. Ибо железо дешевеет с каждым днем.


Уровней изоляции по стандарту гораздо больше чем 2.
Я например, не ожидаю на блокировке,
у меня есть решение(технология) pending list (C)
которая решает эти ситуации на 99 процентов
(кроме случая сна в курсоре на блокировке, этот прогЛамер
для начала лишается премии).

ИМНО Если база быстрая, то она блокировочник. Если у вас быстрый версионник то готовтесь разгребать проблемы с целоснтостью данных.
Имеется ввиду настоящее многопользовательское приложение.
И рыбку съесть и на %#~ сесть не получится.

With regards
5 сен 04, 14:14    [935412]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
strizh
Member

Откуда: Киев
Сообщений: 937
Може такое уже предлагали, но мне при большом времени выполнения
select count(*)
сильно помогло
select count(key_filed)
Об этом даже разработчики говорят (в этом же форуме проскакивало), что в Постгресе в функцию count лучше всего подставлять первичный ключ, иначе у сервера возникают проблемы с версионностью записей, вот он и думает хто зна сколько.
7 сен 04, 19:42    [941407]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
автор
Прошу прощения, что надолго пропал.


Также прошу прощения. Отпуск - это святое. :-)

автор
Мне почему-то кажется, что пробежаться по индексу по записям число которых 10-20к - это должно быть быстро.


А если все эти записей находятся на разных дисковых страницах? Прочитать 10-20к страниц дисковой системе - это быстро?

автор
смущает то, что в тесте создания таблицы, предложенного LeXa NalBat, разница в 2.5 раза :(


Я тестировал на такой машине: два проца Xeon 2.8; 2Gb ОЗУ; 320 SCSI контроллер + два 320 SCSI HDD в RAID 0; ось Linux 2.4.21-SuSE.

автор
Но ведь реально мне нужно не настолько простой запрос, который уже "лезет" в таблицу


Работая в свое время на оракле, мы для этого запихивали в индексы (в конец) все поля таблицы. Размер индекса из-за этого во много раз увеличивался, но получался выигрыш в скорости выполнения выборки, так как оракл все данные брал из индекса не заглядывая в таблицу.
8 сен 04, 10:06    [942050]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Случайно заглянул
Guest
LeXa NalBat
автор
Прошу прощения, что надолго пропал.


Также прошу прощения. Отпуск - это святое. :-)

автор
Мне почему-то кажется, что пробежаться по индексу по записям число которых 10-20к - это должно быть быстро.


А если все эти записей находятся на разных дисковых страницах? Прочитать 10-20к страниц дисковой системе - это быстро?


Особенно если они лежат не подряд.


автор
смущает то, что в тесте создания таблицы, предложенного LeXa NalBat, разница в 2.5 раза :(


Я тестировал на такой машине: два проца Xeon 2.8; 2Gb ОЗУ; 320 SCSI контроллер + два 320 SCSI HDD в RAID 0; ось Linux 2.4.21-SuSE.

автор
Но ведь реально мне нужно не настолько простой запрос, который уже "лезет" в таблицу


Работая в свое время на оракле, мы для этого запихивали в индексы (в конец) все поля таблицы. Размер индекса из-за этого во много раз увеличивался, но получался выигрыш в скорости выполнения выборки, так как оракл все данные брал из индекса не заглядывая в таблицу.


Не факт. Если по статистике в виборку попадает более 10% все данных из
таблицы oracle делает полное сканирование. И это всегда быстрее засчет
мультиблочного и опережающего чтения.
Зато на скорости вставки и удаления вы проиграли в сотни раз.
8 сен 04, 11:02    [942338]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Случайно заглянул

Как красиво :) easy way. Купил базу и на коленке слабал продукт.

Представим бухгалтерию сесия (сеcсия S2) дебитует счет,
При этом сесия S1 дебитует тот-же счет.
То есть получится, Если сумма по транзакциям S1+S2 больше остатка на счете, одна из них должна отклониться по недостатку средств. Но этого
не произойдет. И окончательное значение остатка не будет учитывать
транзакцию которая завершилась раньше.
А потом еще вы очень долго будете искать откуда у вас касса(склад)
разезжаются с бухгалтерией.
Описанный вами пример - часный случай грязного чтения.


Это опять тот пример, который апологеты MSSQL приводят в пику Oracle?
Ну если вы так печетесь о целостности, то наверно имеет смысл говоить, что операция дебетирования счета не может параллелиться, а она есть строго последовательна, и архитектура СУБД тук как бы ни причем.
В этом случае практичекси все едино какую СУБД вы возьмете, хоть обычный плоский файл , суть от этого не меняется и эта суть - "Последовательный доступ к данным".
Причем здесь версионность СУБД, имеет смысл говорить о последовательности исполнения транзакций, а не о конкурентном доступе к данным.
В этом случае вопрос производительности просто нет смысла поднимать, а следует уже говорить о "Transaction-Level Read Consistency".
А для этого у Oracle есть.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Случайно заглянул

Oracle кстате версиониик только внешне, внутри он все такой же блокировочник.
ИХМО постоянное возникновенни ошибки ORA-1555 Snapshot too old
коственно говорит о кривости рук проектировщика базы.

Если нет желания настраивать сегменты отката, то так и будет, это скорей вопрос "кривости" рук админа.

А если мы говорил про версию 9i, то установкой retantion_time в нужное значение + наличием дополнительного дискового пространства можно добиться того чтобы ORA-1555 не появлялась.
Если говорим про 8i там настройка сегментов сложнее , но так же реально избежать ORA-1555.



Случайно заглянул

ИМНО Если база быстрая, то она блокировочник. Если у вас быстрый версионник то готовтесь разгребать проблемы с целоснтостью данных.
Имеется ввиду настоящее многопользовательское приложение.
И рыбку съесть и на %#~ сесть не получится.

With regards

Это спорно.
Пример ?
В Юконе наконец-то появиться возможность неблокирующего чтения ( читай версиионность ),
чтобы народ наконец-то почувствовал как оно без блокировок по чтению жить.
Я думаю это не спроста.
А вы ?
8 сен 04, 11:12    [942392]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Случайно заглянул

Не факт. Если по статистике в виборку попадает более 10% все данных из
таблицы oracle делает полное сканирование. И это всегда быстрее засчет
мультиблочного и опережающего чтения.
Зато на скорости вставки и удаления вы проиграли в сотни раз.

Не факт.
Завист от параметров настройки и в конце концов в каждом конкретном случае может использоваться по разному.
http://www.oradba.com.ru/tuning/optimizer/articles/a2_srchintellcbo/page11.shtml

Мы так же може использовать IOT вместо индекса, опять же зависит от условий задачи , и что мы хотим получить в конце.
8 сен 04, 11:21    [942450]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
Случайно заглянул
Если по статистике в виборку попадает более 10% все данных из таблицы oracle делает полное сканирование.


У нас подавляющая часть выборок - около 20-ти строк.

Случайно заглянул
Зато на скорости вставки и удаления вы проиграли в сотни раз.


Не в сотни, а в несколько раз из-за специфики задачи. Удаление/добавление происходило раз в сутки массированно по алгоритму: drop index, delete 20% строк, insert 20% строк, create index.
8 сен 04, 11:36    [942524]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Случайно заглянул
Guest
EugeneS
Случайно заглянул

Как красиво :) easy way. Купил базу и на коленке слабал продукт.

Представим бухгалтерию сесия (сеcсия S2) дебитует счет,
При этом сесия S1 дебитует тот-же счет.
То есть получится, Если сумма по транзакциям S1+S2 больше остатка на счете, одна из них должна отклониться по недостатку средств. Но этого
не произойдет. И окончательное значение остатка не будет учитывать
транзакцию которая завершилась раньше.
А потом еще вы очень долго будете искать откуда у вас касса(склад)
разезжаются с бухгалтерией.
Описанный вами пример - часный случай грязного чтения.


Это опять тот пример, который апологеты MSSQL приводят в пику Oracle?
Ну если вы так печетесь о целостности, то наверно имеет смысл говоить, что операция дебетирования счета не может параллелиться, а она есть строго последовательна, и архитектура СУБД тук как бы ни причем.
В этом случае практичекси все едино какую СУБД вы возьмете, хоть обычный плоский файл , суть от этого не меняется и эта суть - "Последовательный доступ к данным".
Причем здесь версионность СУБД, имеет смысл говорить о последовательности исполнения транзакций, а не о конкурентном доступе к данным.
В этом случае вопрос производительности просто нет смысла поднимать, а следует уже говорить о "Transaction-Level Read Consistency".
А для этого у Oracle есть.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;



Не будем уходить от темы начиналсь все с

Зл0й

Oracle - версионник. Соотвественно пока объемов Rollback Segment'ов хватает, вы можете одновременно писать и читать одну и ту же таблицу в разных сессиях. Без взаимных блокировок и грязного чтения. . Этим Оракл выгодно отличается от Teradata и DB2. Поясню примером


Не кажется ли вам что вы противоречите концепции версионности и
и предидущему оратору. Что говорит о том, что oracle не совсем версионник.
Зачем версионнику ISOLATION LEVEL SERIALIZABLE. У него есть версионные механизмы поддержания целосности данных. Даже само понятие ISOLATION LEVEL противоречит понятию версионности , не так ли?
В документации по oracle я нигде не встречал
описание понятия версионности. Может процитируете для меня?

Я для вас процетирую :

Oracle Concepts

Transactions and Data Concurrency
Oracle provides data concurrency and integrity between transactions using its locking mechanisms. Because the locking mechanisms of Oracle are tied closely to transaction control, application designers need only define transactions properly, and Oracle automatically manages locking.

Keep in mind that Oracle locking is fully automatic and requires no user action. Implicit locking occurs for all SQL statements so that database users never need to lock any resource explicitly. Oracle's default locking mechanisms lock data at the lowest level of restrictiveness to guarantee data integrity while allowing the highest degree of data concurrency.


Автоматическое управление блокировками это не версионность,
я это имел ввиду когда говорил о внутреннем строении oracle как блокировочника.


EugeneS

Если нет желания настраивать сегменты отката, то так и будет, это скорей вопрос "кривости" рук админа.

А если мы говорил про версию 9i, то установкой retantion_time в нужное значение + наличием дополнительного дискового пространства можно добиться того чтобы ORA-1555 не появлялась.
Если говорим про 8i там настройка сегментов сложнее , но так же реально избежать ORA-1555.


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

EugeneS

Случайно заглянул

ИМНО Если база быстрая, то она блокировочник. Если у вас быстрый версионник то готовтесь разгребать проблемы с целоснтостью данных.
Имеется ввиду настоящее многопользовательское приложение.
И рыбку съесть и на %#~ сесть не получится.

With regards

Это спорно.
Пример ?

В Юконе наконец-то появиться возможность неблокирующего чтения ( читай версиионность ),
чтобы народ наконец-то почувствовал как оно без блокировок по чтению жить.
Я думаю это не спроста.
А вы ?



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

Грязное чтение тоже никого не блокирует, но это не версионность.
Так что читать пока нечего. :) Или там не только чтение, а полная версионность.
8 сен 04, 13:13    [943059]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Случайно заглянул

Зл0й

Oracle - версионник. Соотвественно пока объемов Rollback Segment'ов хватает, вы можете одновременно писать и читать одну и ту же таблицу в разных сессиях. Без взаимных блокировок и грязного чтения. . Этим Оракл выгодно отличается от Teradata и DB2. Поясню примером


Не кажется ли вам что вы противоречите концепции версионности и
и предидущему оратору. Что говорит о том, что oracle не совсем версионник.
Зачем версионнику ISOLATION LEVEL SERIALIZABLE. У него есть версионные механизмы поддержания целосности данных. Даже само понятие ISOLATION LEVEL противоречит понятию версионности , не так ли?
В документации по oracle я нигде не встречал
описание понятия версионности. Может процитируете для меня?



Преждем чем я отвечу.
Дайте определение того, что вы называете версионником?
И пример программных продуктов которые по вашему являются "чистым версиионником" ?
8 сен 04, 13:43    [943248]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
Carrie
Member

Откуда:
Сообщений: 17
LeXa NalBat

А если все эти записей находятся на разных дисковых страницах? Прочитать 10-20к страниц дисковой системе - это быстро?

Мне кажется да. Как-нибудь попробую протестить.

LeXa NalBat

Я тестировал на такой машине: два проца Xeon 2.8; 2Gb ОЗУ; 320 SCSI контроллер + два 320 SCSI HDD в RAID 0; ось Linux 2.4.21-SuSE.

У меня 2 x XEON2.4Ghz, 2Gb RAM, интегрированный SCSI-контроллер, 4x36Gb SCSI (не в рейде). ось RHEL AS-3.0. Время теста смог уменьшить до 5мин 10сек. Но все равно в 2 раза дольше чем у вас) Кстати, очень похоже на то, что разницу такую дает использование RAID0.

В общем, я практически уже определился что как буду делать. Сейчас с недели две протестирую на реальных данных еще раз, посмотрю под нагрузкой и т.п. Структуру базы оставлю как она есть, только внесу в нее, как посоветовали, избыточные таблицы, которые будут содержать разные агрегаты основных таблиц. В общем эдакий OLAP "на коленке".
В следующей версии буду смотреть уже в сторону Sybase IQ (на первый взгляд то, что нужно), IBM DB2 (уж очень заманчиво выглядят MDC-таблицы), возможно Oracle с его partitioned tables.
Единственный вопрос, который остался, это касательно postgres'а. Размер таблицы на диске, содержащей, например, только целые поля, в среднем в 6 раз больше, чем произведение колво_строк_таблицы*размер_строки_в_байтах. Не очень критично, но хотелось бы чтобы приблизительно один к одному было, как например в myisam (в innodb, например, этот коэффициент равен уже 4).
9 сен 04, 08:12    [945444]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для быстрой работы с большими таблицами.  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
автор
> Прочитать 10-20к страниц дисковой системе - это быстро?

Мне кажется да. Как-нибудь попробую протестить.


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

автор
Кстати, очень похоже на то, что разницу такую дает использование RAID0.


Я тоже думаю, что это именно RAID 0. Кроме того наш админ сказал (я плохо разбираюсь в железе), что SCSI-контроллер и диски быстрые - 320 Mb/sec.

автор
Единственный вопрос, который остался, это касательно postgres'а. Размер таблицы на диске, содержащей, например, только целые поля, в среднем в 6 раз больше, чем произведение колво_строк_таблицы*размер_строки_в_байтах. Не очень критично, но хотелось бы чтобы приблизительно один к одному было, как например в myisam (в innodb, например, этот коэффициент равен уже 4).


Я не знаю ответа на этот вопрос. Наверное надо читать где-то в разделе internals в доке. Может быть вам задать этот вопрос в конфе постгреса?
9 сен 04, 10:02    [945652]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить