Здравствуйте, Alexey Shirshov, Вы писали:

AS>Прям минуя ядро ОС и его дисковый кеш менеджер?
Именно так.

AS>Более того, никогда данные не пишутся на диск сразу же. Они попадают в buffer pages менеджера буферов, откуда по checkpoint-у перекачиваются на диск.
По чекпоинту данные из лога перебрасываются в основную базу. При фиксации данные всегда сбрасываются на диск в лог — это азбука.


AS>Так что Ваня, марш учить теорию и читать Дилани.
Ты это кому-нибудь другому говори.

Здравствуйте, Alexey Shirshov, Вы писали:


AS>C Merle бесполезно спорить. Он глух как support@rsdn.ru и никогда не признается, что лоханулся. Ведь модер форума БД, да еще и такой парень как Merle просто не может лохануться!
Алекс, забываешься. Фиг бы с ним но ты еще не прав и по сути дела.

AS>А то, что он немного путает сброс данных и запись log records в лог — ну это не беда.
А теперь расскажи мне, что такое Log records. И как именно они пишутся в лог пишутся в лог, что такое лог и зачем он вообще нужен.
Нет, я жду.



AS>В конце концов, он всегда тебе сможет доказать, что log records это тоже ведь данные!
Нет, не данные? А что это, расскажи пожалуйста?

Здравствуйте, DarkGray, Вы писали:

DG>Дело-то не сколько памяти адресуется и поддерживается чипсетом, а сколько это память стоит.
Вот и я о том же. Мы еще IA32 не исчерпали, а уже ждем панацеи от Amd64. Бред. Вопрос именно в том, что пока мало кто может себе позволить сервак с более чем 4 GB памяти.

Здравствуйте, avbochagov, Вы писали:

A>Скорость разработки не увеличивается. Она такая же.
A>А вот скорость работы заметно выше.
Вот странно, что success stories все больше говорят об ускорении разработки, а не о увеличении производительности. Но тебе, наверное, виднее.

Здравствуйте, Anatolix, Вы писали:
S>>Согласен. РБД — не панацея. Просто потому, что большинство из них садится в лужу на "простейших" запросах типа select * from plane where (x-x0)*(x-x0)+(y-y0)*(y-y0)<R*R

A>На них все садятся. Объектная БД требует специальную структуру данных чтобы такие запросы быстро выполнять. При этом если у тебя формула измениалась то программу переделывать в объектной базе сложнее.

A>В реляционной достаточно сделать индекс по вычисляемому полю, или просто это поле хранить в таблице, заполнять триггером можно (а можно и руками).
Увы. В приведенном примере никакого вычисляемого поля ввести нельзя. Нужно рассматривать нелинейные системы индексации, про которые, к слову, почти ничего и не разработано. Коммерчески, вроде как, применяются R-деревья и Mail-деревья.

Здравствуйте, Alexey Shirshov, Вы писали:
AS>А каким образом хорошая скорость B+tree может быть связана с дисковыми операциями?
Таким, что оно минимизирует количество обращений к диску, а не разыменования указателей в памяти. Вот и всё.

Здравствуйте, Serginio1, Вы писали:

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DarkGray, Вы писали:

DG>>Дело-то не сколько памяти адресуется и поддерживается чипсетом, а сколько это память стоит.
S>Вот и я о том же. Мы еще IA32 не исчерпали, а уже ждем панацеи от Amd64. Бред. Вопрос именно в том, что пока мало кто может себе позволить сервак с более чем 4 GB памяти.
Для домашних комьтеров это уже норально, а ты о серверах. Стоимость Amd64 на порядки ниже IA32 и UltraSPARC
Прочти про Sun Fire V20z http://www.amdnow.ru/#1080436001 3 килобакса совсем не подъемная цена по сравнению со стоимостью програмного обеспечения????
Или все мыслить старыми категориями ,правда концепции SQL еще старее.

Здравствуйте, Alexey Shirshov, Вы писали:

AS>Прям минуя ядро ОС и его дисковый кеш менеджер?
Именно так, читай CreateFile, флаг FILE_FLAG_WRITE_THROUGH.

FILE_FLAG_WRITE_THROUGH
Instructs the system to write through any intermediate cache and go directly to disk. The system can still cache write operations, but cannot lazily flush them.

AS>Более того, никогда данные не пишутся на диск сразу же. Они попадают в buffer pages менеджера буферов, откуда по checkpoint-у перекачиваются на диск.
Ты либо что-то не то читаешь, либо где-то не там. Берем MSSQL, простейшая транзакция.

BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION

А теперь смотрим какие действия выполняются при выполнении подобной операции:

BEGIN TRANSACTION Written to the log cache area but there is no need to flush to stable storage because the SQL Server has not made any physical changes.

INSERT INTO tblTest
1. Data page is retrieved into SQL Server data cache, if not already available.
2. The page is latched, pinned, and marked dirty, and appropriate locks are obtained.
3. An Insert Log record is built and added to the log cache.
4. A new row is added to the data page.
5. The latch is released.
6. The log records associated with the transaction or page does not need to be flushed at this point because all changes remain in volatile storage.

COMMIT TRANSACTION
1. A Commit Log record is formed and the log records associated with the transaction must be written to stable storage. The transaction is not considered committed until the log records are correctly assigned to stable storage.
2. Data page remains in SQL Server data cache and is not immediately flushed to stable storage. When the log records are properly secured recovery can redo the operation if necessary.
3. Transactional locks are released.

То есть, в доке к сиквелу английским по белому написано, что log records должны сбросится на диск при фиксации транзакции. log records содержит сами данные, для того, чтобы в случае любого сбоя эти данные можно было бы накатить на основную базу. Надеюсь, для тебя не сюрприз, что весь дисковый обмен в СУБД идет постранично, то есть даже если на диске надо поменять 1 байт, то перезаписывается вся страница целиком.

А теперь объясни мне пожалуйста, чем, в контексте нашего разговора, это лучше чем просто сброс страницы данных на диск (в плане производительности)?

И так, еще раз. Я утверждаю, что при фиксации транзакции данные обязаны быть сброшены на диск — будешь спорить?

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Alexey Shirshov, Вы писали:

AS>>Прям минуя ядро ОС и его дисковый кеш менеджер?
M>Именно так, читай CreateFile, флаг FILE_FLAG_WRITE_THROUGH.
M>

M>FILE_FLAG_WRITE_THROUGH
M>Instructs the system to write through any intermediate cache and go directly to disk. The system can still cache write operations, but cannot lazily flush them.

О каком кэше идет речь. Так как система сама кэширует страницы. А есть еще кэш диска который наращивается в Raid массивах?????
Каков дневной объем лога??? Разницы нет что записывать байт что страницу.

Здравствуйте, Serginio1, Вы писали:

S> О каком кэше идет речь. Так как система сама кэширует страницы. А есть еще кэш диска который наращивается в Raid массивах?????
Еще раз повторюсь. Во всех mission critical системах все аппаратные кеши на запись настоятельно рекомендуют отключать.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> О каком кэше идет речь. Так как система сама кэширует страницы. А есть еще кэш диска который наращивается в Raid массивах?????
M>Еще раз повторюсь. Во всех mission critical системах все аппаратные кеши на запись настоятельно рекомендуют отключать.
И еще записывать в амбарную книгу (и это не шутка видел и такие вещи).
Давай все таки определимся и займемся арифметикой. Журнал транзакций необходимая вещь и однозначно должна быть прописана любая трнзакция. Но под него как правило отводится отдельный диск. Какова скорость записи на современные диски???? Каков объем информации записываемой например за день???
Каково время записи единичной информации????
В иоге получим суммарное время записи в журнал транзакций. Очень интересно узнать эту величину.
И сравнить с временем доступа к записям обсчет результатов и уже самой конечной фазой — запись.

Здравствуйте, Serginio1, Вы писали:

S> Так разговор на данном этапе даже не о записи а о чтении и расширенной организации данных.
Да, я намеренно избегал говорить о записи. Там все начинает жить несколько по-другому. Скорость тут ни при чем, вопрос в том — не напоремся ли мы при использовании RID на необхдимость перезаписи ссылок? Как там с дефрагментацией удаленного дело обстоит?
S>Вы Синклеером говорите что ООП на стороне сервера это тормоза, а я что нет и даже во многих случаях выигрышь.
Нет, я этого нигде не говорил. Просто ты валишь в одну кучу совершенно не связанные между собой вещи. ООП не имеет никакого отношения к иерархическим базам данных; они, в свою очередь, не имеют никакого отношения к проблеме RID vs PK.
S>А нужна прежде всего гибкость и скорость разработки а не за сколько выполнится тот или иной запрос.
Вот второе высказывание с твоей стороны в этой беседе, c которым я могу согласиться. Ты в следующий раз так и начинай с разумных вещей, а не рассказывай про то, как двусвязные списки побеждают RDBMS Я все же не вполне согласен, в том смысле, что совсем отменить требования performance нельзя. Но важность скорости разработки, конечно же, рулит чем дальше, тем сильнее.
S>ECO, OBjectSpasec на сторону сервера!!!!!
Итак, предлагаю закончить эту дискуссию на постулировании трех вещей:

1. Алгоритмы, применяемые в RDBMS, были разработаны для условий нехватки вычислительных мощностей и памяти
2. Снижение стоимости памяти может сделать оправданным применение на низком уровне тех алгоритмов, которые ранее игнорировались в мире RDBMS
3. Снижение стоимости вычислительных мощностей выдвигает на первый план скорость разработки систем, а не быстродействие при эксплуатации, что может сделать оправданным применение на низком уровне тех алгоритмов, которые ранее игнорировались в мире RDBMS.

Следующий виток — в новой ветке

Здравствуйте, Serginio1, Вы писали:
S> Для домашних комьтеров это уже норально, а ты о серверах. Стоимость Amd64 на порядки ниже IA32
Ну хватит с темы-то съезжать, а? Тебе русским по белому пишут: для СУБД неважно, что применяется, Pentium IV или Athlon 64. Память для них стоит одинаково. Ты тут пел про какие-то проблемы с адресным пространством, которые якобы решаются с помощью 64 разрядов. Так вот — НЕТ этих проблем. Уже 10 лет как нету.

Здравствуйте, Merle, Вы писали:

Блин, Иван, ну дай ты ему возможность тебя поймать, а? Мы вообще не про запись говорили. И не стоит про нее начинать, потому что эта тема никакого отношения к RID vs PK не имеет, равно как и к противоборству иерархических СУБД с реляционными. Техника протоколирования никак не меняется.
Да, действительно, на практике если у тебя working set относительно небольшой, то ты можешь вообще никогда не выполнять считывания с диска. Ну поменял ты состояние страницы, даже если выбранная схема протоколирования требует ее отфлашить — ну и пес с ним, пока тебе не понадобилось место в страничном кэше — можно ничего не читать. Вообще интересная теория — классики рассматривают случаи неприменимости двухпроходных алгоритмов, а у нас вообще все полгига базы можно в память отмапить, и еще полтора для временных отношений останется.

Вопрос-то теперь ровно в том: каков характерный размер дополнительной памяти необходим под временные буфера, если все join происходят исключительно при помощи RID? И не окажется ли так, что мы всегда для таких случаев сможем применять алгоритмы с пайплайнингом, оставляя для более екзотических джойнов старые добрые B-деревья?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>> Для домашних комьтеров это уже норально, а ты о серверах. Стоимость Amd64 на порядки ниже IA32
S>Ну хватит с темы-то съезжать, а? Тебе русским по белому пишут: для СУБД неважно, что применяется, Pentium IV или Athlon 64. Память для них стоит одинаково. Ты тут пел про какие-то проблемы с адресным пространством, которые якобы решаются с помощью 64 разрядов. Так вот — НЕТ этих проблем. Уже 10 лет как нету.
Это не я пел а Вы про память дисковые операции итд. Спасибо впервые узнал что проблема адресного пространства решена аж 10 лет тому назад по стоимости близкой к домашнему компьютеру. Буду знать. И чего это 64 разрядной виндовс еще нет в релизе??? Да и M$ только недавно анансировало 64 SQL Server и хвастались что количество транзакций в секунду у них дико выросли.
А сколько стоят спарки???? И сколько у тебя памяти на самом могучем серверое????

Здравствуйте, Sinclair, Вы писали:

S>Блин, Иван, ну дай ты ему возможность тебя поймать, а?
Да что я, против что ли? Пусть ловит, только по делу, а он же откровенную глупость говорит.

S>Мы вообще не про запись говорили. И не стоит про нее начинать, потому что эта тема никакого отношения к RID vs PK не имеет, равно как и к противоборству иерархических СУБД с реляционными.
Имеет, хотя, возможно, не в первом приближении.

S>Да, действительно, на практике если у тебя working set относительно небольшой, то ты можешь вообще никогда не выполнять считывания с диска.
Ну вообщем да. Только на таких системах (где все данные в память влезают) разница в разы между использованием хеш-таблицы и дерева на время отклика практически никакого эффекта не оказывает. Эти разы, по любому микросекунды.
А вот как только размер базы вырастает на столько, что в память перестает помещаться (а БД имеют свойство расти), то деревья сразу же начинают выигрывать, причем существенно.

S> Ну поменял ты состояние страницы, даже если выбранная схема протоколирования требует ее отфлашить — ну и пес с ним, пока тебе не понадобилось место в страничном кэше — можно ничего не читать. Вообще интересная теория — классики рассматривают случаи неприменимости двухпроходных алгоритмов, а у нас вообще все полгига базы можно в память отмапить, и еще полтора для временных отношений останется.
Но опять-таки, это все шевелится ровно до тех пор, пока база влезает в память, а гарантировать это можно далеко не всегда.

S>Вопрос-то теперь ровно в том: каков характерный размер дополнительной памяти необходим под временные буфера, если все join происходят исключительно при помощи RID?
Каким образом? У нас для каждой записи будет прямая ссылка на остальные записи? Для всех связей, которые могут быть в системе?

S>И не окажется ли так, что мы всегда для таких случаев сможем применять алгоритмы с пайплайнингом, оставляя для более екзотических джойнов старые добрые B-деревья?
А смысл? Возможно это того и стоит, но в первом приближении выигрыш в несколько раз, это микросекунды. И вполне может оказаться так, что сложность сопровождения всего этого хозяйства окажется дороже.
Что-то мне не очень верится пока в эту идею.

DG>>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы.
S> 6-9 килобаксов.

128гб? ссылку, пожалуйста.

DG>>Если же, например, описания идут не plain-текст, а rich-текстом (doc, html, xml), то описание уже может быть и 2000 символов, и четыре тысячи, а ведь скорее всего захочется и full-text index по этим описаниям- это еще одна копия этих же данных и т.д.
S> А кто предлагал использовать doc, html, xml.

Пользователь.


S> Речь идет о несколько другой организации хранения данных и работа с данными как в локальных базас с ООП надстройкой над хранимыми данными и обрабокой на стороне сервера. Теже ECO ObjectSpace работают только на стороне клиента. На стороне сервера этого нет. Для объектного подхода нужени быстрый доступ по ссылкам а это можно решить введение прямой ссылки (номер записи)

Что мешает сделать индекс для реляционной базы, который будет хранить эту прямую ссылку?

ИМХО, проблема не в прямых ссылках, а в том, что реляционная база не поддерживает полиморфизм.
Если у нас есть таблица "одежда", и таблица "еда", то сделать таблицу "отгружаемый товар" — очень тяжело.
Потому что реляционная база не поддерживает ссылкы на разнотипные (из разных таблиц) данные.

Но может это просто стоит прикрутить к реляционное базе?

S> Да огромная цифра. Есть фирмы с множеством складов по 20 компьютеров и у каждого очередь. И работали на DBASE но это простейшие операции где сложный расчет не нужен.

Такие базы очень примитивные, и плохо покрывают реальные запросы менеджеров.
Менеджера интересуют следующие фичи:
1. На сколько эффективно используется складское помещение?
2. Автоматическое формирование цены на основе ряда показателей (закупочная цена, налоги, курс валюты)
3. Кластеризация покупателей, а также стандартная корзина каждого кластера
4. Оплата платежей, используя пластиковые карточки, корпоративные счета и т.д.
5. Гибкая система формирования скидок.
и т.д.

Здравствуйте, Serginio1, Вы писали:

S> Каково время записи единичной информации????
S> В иоге получим суммарное время записи в журнал транзакций. Очень интересно узнать эту величину.
S> И сравнить с временем доступа к записям обсчет результатов и уже самой конечной фазой — запись.
Занимательная статистика...
Конкретные цифры не знаю, но частенько наблюдал, как транзакции выстраиваются в очередь, читобы записать данные на диск. Очередь не на блокировках, ни на чем-то еще, а именно ожидание пока физическое устройство освободится и сможет записать/считать очередную порцию данных. Пропускную способность диска ты знаешь лучше меня, она здесь ограничивающий фактор, вот и считай какой объем данных проползает в день через такую систему.