Здравствуйте, Serginio1, Вы писали:
S> То есть кэширование страниц не используется и ассинхронной записи на диск не существует??? Но это их беды.
Именно не используется, и именно не существует. И это не их беды, это требования устойчивости транзакций. Без этого ни о какой надежности речи идти не может.
В Mission critial системах даже аппаратные write back кеши отключают, тем более, что пользы от них не очень много.
S> То есть БД работает не со страницами в памяти а только с диском (да и то система кэширут их в памяти).
Какая система? ОС не кеширует ничего — все дисковые операции БД производит напрямую.
S> Асинхронно.
Хрен там. Никакой асинхронности. Пока БД не убедится, что данные доехали до диска, commit не произойдет, все блокировки будут удерживаться, ect...
Тебе уже три человека говорят, почитай же теорию наконец, поймешь, почему все сделано именно так.
S> Их не так и много даже сейчас за счет кэширования. При чем если бы было наоборот то и SQL особо не поворочаешь все сразу уперлось бы в чтение диска а это не так.
Не поверишь, но это именно так. В большинстве систем диск самое узкое место.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Alexey Shirshov, Вы писали:
AS>> Синхронно на диск уходит запись в лог. M>Ну и какая разница? Запись в лог — не дисковая операция? Страница лога пишется в разы быстрее? M>Один фиг к диску обращаться. Почитал бы и ты теорию что ли....
И какое имеет это отношение к выборкам данных???? И можно легко посчитать затраты на лог как дымаешь какими они окажутся и сколько процентов по времени будут занимать по отношению к общим затратам ???? у диска свой кэш есть.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Все о чем SQL выигрывает вернее сильная часть это глобальные выборки, т.к. в примере подсчета продаж в день он опускает руки .
??? SQL? Первый раз слышу. Хотя с кривыми руками можно действительно любую систему положить..
S>Но в задач с проведением документов а они и являются основными критическими затратами это не нужно.
Что не нужно?
S> Select * From s where ID=:ID Согласен что такой запрос будет скомпилирован, но SetPrimsryIndex, GetRecordForKey(ID) и как видишь кода лишнего совсем немного.
О чем ты? При чем тут скомпилирован?
S> Тебе показать проведение начисления зарплаты???? Где тысячи ветвлений.
И ты предлагаешь эти тысячи ветвлений в ручную описывать? Флаг в руки.
S> Если бы все было так просто. Парус нормальную бухгалтерию выпустить не может. А все потому что структура бухгалтерии не однородна и не вписывается в прямолинейные запросы SQL. А таких задач пруд пруди.
Бухгалтерия в SQL вписывается идеально, его не в последнюю очередь именно для таких задач и придумывали. Поверь, гораздо проще разобраться наконец с тем как это правильно работает, а не городить велосипед с квадратными колесами.
Здравствуйте, Serginio1, Вы писали:
S> И какое имеет это отношение к выборкам данных????
Прямое.
S>И можно легко посчитать затраты на лог как дымаешь какими они окажутся и сколько процентов по времени будут занимать по отношению к общим затратам ????
Достаточное, чтобы быть узким местом.
S> у диска свой кэш есть.
Блин, в 5й раз говорю. Все обращения к диску идут в обход всех кешей. RTFM.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> То есть кэширование страниц не используется и ассинхронной записи на диск не существует??? Но это их беды. M>Именно не используется, и именно не существует. И это не их беды, это требования устойчивости транзакций. Без этого ни о какой надежности речи идти не может. M>В Mission critial системах даже аппаратные write back кеши отключают, тем более, что пользы от них не очень много.
S>> То есть БД работает не со страницами в памяти а только с диском (да и то система кэширут их в памяти). M>Какая система? ОС не кеширует ничего — все дисковые операции БД производит напрямую.
Пусть будет так. И каковы затраты на запись. Давай посчитаем 20ГБ в сек скорость записи не самого хорошего диска. Сколько данных в секунду записывается в реальной базе?????
За весь рабочий день столько не наберется. S>> Асинхронно. M>Хрен там. Никакой асинхронности. Пока БД не убедится, что данные доехали до диска, commit не произойдет, все блокировки будут удерживаться, ect...
M>Тебе уже три человека говорят, почитай же теорию наконец, поймешь, почему все сделано именно так.
S>> Их не так и много даже сейчас за счет кэширования. При чем если бы было наоборот то и SQL особо не поворочаешь все сразу уперлось бы в чтение диска а это не так.
И как они еще ворочаются. 20ГБ в сек значит предел для них. А вы тут SQL SQL. M>Не поверишь, но это именно так. В большинстве систем диск самое узкое место.
То есть если страницы в памяти то они все равно каждый раз считываются с диска???? Запись в БД занимаю небольшие затраты по сравнению с чтением.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> И какое имеет это отношение к выборкам данных???? M>Прямое.
S>>И можно легко посчитать затраты на лог как дымаешь какими они окажутся и сколько процентов по времени будут занимать по отношению к общим затратам ???? M>Достаточное, чтобы быть узким местом.
S>> у диска свой кэш есть. M>Блин, в 5й раз говорю. Все обращения к диску идут в обход всех кешей. RTFM.
Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Дело-то не сколько памяти адресуется и поддерживается чипсетом, а сколько это память стоит.
если считать по цене памяти для обычных персоналок: 256мб — 60$, 128г ~ 3000$, вспомним, что это память для сервера (* 2-5), что все 128гб память надо уместить в маленький объем (* 3-10), вспомним, что эта память будет выпускается малыми партиями, поэтому себестоимость высокая (* 3-10), такая память наукоемкая, требующая быстрой отдачи с вложенных денег (* 2-5)
Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы.
Тем более 128гб памяти — это не так уж много, 1млн простых записей вида имя, описание, дата, цена, где имя — 100 символов, описание — 500 символов, получается 1млн * (100 символов + 500 символов) * 2 байт/символ = 1.2гб, т.е. в памяти поместится всего 100 таблиц, это не считая всяких overhead-ов, кэшей и т.д.
Если же, например, описания идут не plain-текст, а rich-текстом (doc, html, xml), то описание уже может быть и 2000 символов, и четыре тысячи, а ведь скорее всего захочется и full-text index по этим описаниям- это еще одна копия этих же данных и т.д.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Все о чем SQL выигрывает вернее сильная часть это глобальные выборки, т.к. в примере подсчета продаж в день он опускает руки . M>??? SQL? Первый раз слышу. Хотя с кривыми руками можно действительно любую систему положить..
Бедный Sinclair, не знал что у него кривые руки. S>>Но в задач с проведением документов а они и являются основными критическими затратами это не нужно. M>Что не нужно?
S>> Select * From s where ID=:ID Согласен что такой запрос будет скомпилирован, но SetPrimsryIndex, GetRecordForKey(ID) и как видишь кода лишнего совсем немного. M>О чем ты? При чем тут скомпилирован?
S>> Тебе показать проведение начисления зарплаты???? Где тысячи ветвлений. M>И ты предлагаешь эти тысячи ветвлений в ручную описывать? Флаг в руки.
А куда деваться такой очень мудренный алгоритм придуманный нашими мудрыми законотворцами.
S>> Если бы все было так просто. Парус нормальную бухгалтерию выпустить не может. А все потому что структура бухгалтерии не однородна и не вписывается в прямолинейные запросы SQL. А таких задач пруд пруди. M>Бухгалтерия в SQL вписывается идеально, его не в последнюю очередь именно для таких задач и придумывали. Поверь, гораздо проще разобраться наконец с тем как это правильно работает, а не городить велосипед с квадратными колесами.
Ты покажи мне этот велосипед. Вот народ тупой всякие Акзапты Навижн 1С используют а тут есть готовое решение и мимо него проходят.
Поделись я посмотрю на реально работающую систему и сравню.
И как вы там с субконто работаете???? Операция имеет множество проводок с различными счетами у которых свой набор субконто, а вид ь проводки может быт только один. Или вы только суммы пишете как насчет аналитики????
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек
Опять не правильно вопрос ставишь.
Не сколько мегабайт в день, а сколько страниц надо сбросить и поднять с диска во время работы одной транзакции и сколько таких транзакций в системе в день проходит.
Точно не скажу, надо мониторить, но можешь мне поверить — вполне достаточно. Особенно эти цифры впечатляют, когда с базой одновременно начинают работать хотя бы десять человек, а не два-три.
S> Пусть будет так. И каковы затраты на запись. Давай посчитаем 20ГБ в сек скорость записи не самого хорошего диска. Сколько данных в секунду записывается в реальной базе????? S> За весь рабочий день столько не наберется.
Не правильно считаешь. 20 Гб пишется за раз, а тут скидываются и поднимаются странички в среднем 8К размером. Да еще в разных частях диска. Так что о 20 Гб можешь забыть.
Тебе не зря ведь приводили стоимость дисковых операций по сравнению со всеми остальными...
S> И как они еще ворочаются. 20ГБ в сек значит предел для них. А вы тут SQL SQL.
Да. занимательная у тебя получается арифметика.
S> То есть если страницы в памяти то они все равно каждый раз считываются с диска????
Нет конечно, но все страницы не с кешируешь.
S> Запись в БД занимаю небольшие затраты по сравнению с чтением.
Не большие, но вполне заметные.
Здравствуйте, DarkGray, Вы писали:
S>> Меня за 3мб убьют. Но в атлонах применяется HypperTrasport до 12 ГБ в секунду (новый до 20). S>> http://www.amdnow.ru/reviews/hypertransport/index3.shtml S>> А как на счет 128 Гбайт(!)
DG>Дело-то не сколько памяти адресуется и поддерживается чипсетом, а сколько это память стоит.
DG>если считать по цене памяти для обычных персоналок: 256мб — 60$, 128г ~ 3000$, вспомним, что это память для сервера (* 2-5), что все 128гб память надо уместить в маленький объем (* 3-10), вспомним, что эта память будет выпускается малыми партиями, поэтому себестоимость высокая (* 3-10), такая память наукоемкая, требующая быстрой отдачи с вложенных денег (* 2-5)
в (2*3) раза. DG>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы.
6-9 килобаксов.
DG>Тем более 128гб памяти — это не так уж много, 1млн простых записей вида имя, описание, дата, цена, где имя — 100 символов, описание — 500 символов, получается 1млн * (100 символов + 500 символов) * 2 байт/символ = 1.2гб, т.е. в памяти поместится всего 100 таблиц, это не считая всяких overhead-ов, кэшей и т.д.
Ну сто тысячные справочники видел (только там наименование пишут) миллионных еще нет. DG>Если же, например, описания идут не plain-текст, а rich-текстом (doc, html, xml), то описание уже может быть и 2000 символов, и четыре тысячи, а ведь скорее всего захочется и full-text index по этим описаниям- это еще одна копия этих же данных и т.д.
А кто предлагал использовать doc, html, xml. Речь идет о несколько другой организации хранения данных и работа с данными как в локальных базас с ООП надстройкой над хранимыми данными и обрабокой на стороне сервера. Теже ECO ObjectSpace работают только на стороне клиента. На стороне сервера этого нет. Для объектного подхода нужени быстрый доступ по ссылкам а это можно решить введение прямой ссылки (номер записи)
и возможно другие подходы для хранения (как двунапрвленные списки, деревья итд). Хранение однотипных данных оптимально хранить в таблицах так что рляционность сохраняется и все наработанные алгоритмы остаются. Тоже дерево может хранится в одной таблице только ссылки на дочерние записи указывают на номер их записи. Все тоже самое только доступ другой.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
S>>> у диска свой кэш есть. M>>Блин, в 5й раз говорю. Все обращения к диску идут в обход всех кешей. RTFM. S> Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек
Возьмем для примера магазин, вот тот же amazon.com.
Вот здесь написано, что у них было 1млн. операций за год, насколько я понимаю — одна операция — одна продажа.
1млн. продаж / 365дней / 24часа / 60минут = 2 продажи в минуту
1 продажа — это не просто запись в одну таблицу, а это авторизация, проверка баланса, перевод денег, выписка накладной, убирание товара со склада и т.д. Каждая из этих операций сопровождается изменением хотя бы одной таблицы.
Кроме продаж, еще есть сессии пользователей, у пользователей есть их настройки и т.д. За пользователями сейчас часто "шпионят", запоминая их предпочтения. И все это тоже надо хранить.
ps
amazon.com — это, конечно, что-то далекое, но можно взять обычный магазин. Возьмем тот же библио-глобус, касс в нем в районе десятка, пустых касс я у них не видел, обслуживание покупателя в районе 1 минуты, т.е. получаем те же 10 продаж в минуту.
ps
Да, учти еще, что в час пик нагрузка может быть в 10-1000 раз быть больше, особенно для online-магазина.
Здравствуйте, Sinclair, Вы писали:
A>>А так — вот A>>http://www.intersystems.com/cache/testimonials/performance.html S>Кул! Червь сомнений меня уже начал мучить. Хотя есть такое подозрение, что у них просто по Sybase не было нормальных спецов... Тем не менее, знак хороший — значит Sybase нифига не чемпион. Шутка На самом деле — получение инструмента, которые позволяет так ускорить разработку даже при небольшом понижении производительности — уже круто. Так что я, в общем, впечатлен. Будем исследовать опыт передовиков OLTP — производства!
Скорость разработки не увеличивается. Она такая же.
А вот скорость работы заметно выше.
S> И какое имеет это отношение к выборкам данных???? И можно легко посчитать затраты на лог как дымаешь какими они окажутся и сколько процентов по времени будут занимать по отношению к общим затратам ???? у диска свой кэш есть.
C Merle бесполезно спорить. Он глух как support@rsdn.ru и никогда не признается, что лоханулся. Ведь модер форума БД, да еще и такой парень как Merle просто не может лохануться!
А то, что он немного путает сброс данных и запись log records в лог — ну это не беда. В конце концов, он всегда тебе сможет доказать, что log records это тоже ведь данные! так что в самом общем смысле он был прав.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек M>Опять не правильно вопрос ставишь. M>Не сколько мегабайт в день, а сколько страниц надо сбросить и поднять с диска во время работы одной транзакции и сколько таких транзакций в системе в день проходит. M>Точно не скажу, надо мониторить, но можешь мне поверить — вполне достаточно. Особенно эти цифры впечатляют, когда с базой одновременно начинают работать хотя бы десять человек, а не два-три.
Очень интересно посмотреть на результаты. Но при объеме памяти больше чем БД на подкачку время не будет тратится.
А по поводу 10 человек то просто с синхронным чтением и записью на откомпилированных выборках и записях это вообще не заметно, т.к. глобальные выборки делаются редко а все остальное занимает милисекунды меньшее чем посылка пакета по сети которые становятся в очередь.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
S>>>> у диска свой кэш есть. M>>>Блин, в 5й раз говорю. Все обращения к диску идут в обход всех кешей. RTFM. S>> Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек
DG>Возьмем для примера магазин, вот тот же amazon.com.
DG>Вот здесь написано, что у них было 1млн. операций за год, насколько я понимаю — одна операция — одна продажа. DG>1млн. продаж / 365дней / 24часа / 60минут = 2 продажи в минуту
Да огромная цифра. Есть фирмы с множеством складов по 20 компьютеров и у каждого очередь. И работали на DBASE но это простейшие операции где сложный расчет не нужен. DG>1 продажа — это не просто запись в одну таблицу, а это авторизация, проверка баланса, перевод денег, выписка накладной, убирание товара со склада и т.д. Каждая из этих операций сопровождается изменением хотя бы одной таблицы.
DG>Кроме продаж, еще есть сессии пользователей, у пользователей есть их настройки и т.д. За пользователями сейчас часто "шпионят", запоминая их предпочтения. И все это тоже надо хранить.
DG>ps DG>amazon.com — это, конечно, что-то далекое, но можно взять обычный магазин. Возьмем тот же библио-глобус, касс в нем в районе десятка, пустых касс я у них не видел, обслуживание покупателя в районе 1 минуты, т.е. получаем те же 10 продаж в минуту.
Только одно забываешь, что работают кассы обычно для безопасности в оффлайне, а внутри обычные ДБФ таблицы. И обычно никаких остатков одни обороты. Да они могут скидывать предварительную информацию на сервер, но там мало контроля за партиями товаров, кредитами итд. И организация таких баз плевое дело. Не в нагрузке а в количестве рассчетов и ветвлений и обращении за дополнительной информации к бд по каждой проводке. В бухгалтерских системах эти затраты огромны. DG>ps DG>Да, учти еще, что в час пик нагрузка может быть в 10-1000 раз быть больше, особенно для online-магазина.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Barmaglot, Вы писали:
A>>Про эффективность говорить не приходится. B>И не говори.
Хорошо, не буду. Просто для примера: крупный магазин работал на системе аналогичной Cache несколько лет, размер все базы (бухгалтерия, склад, и т.д.) не превысил 700МБ — соотвественно сервер P3 266, 128МБ озу.
Сейчас систему сменили на 1с sql — купили сервер P4 2ГГЦ, 1ГБ озу, сокращение рабочих мест с 23 до 8, жалуются что медленно...
A>>Самая крутая РСУБД Oracle "работает одиннаково медленно" на любом объеме данных — описание дано программистом довольно двано работающим с Oracle. B>Давай сюда этого программиста, за базар отвечать будет. Может быть в те времена, когда Оракл была "самой крутой" может быть так и было, но сейчас это совсем не так.
Какая сейчас самая крутая? вопрос без подвоха... просто интересно.
A>>При правильном использовании (как и в любой задаче) применение иерархических СУБД дает примерно выигрыш от 20 до 50 раз по скорости работы (при тех же аппаратно-технических требованиях) B>Угу, только с небольшой поправочкой, а точнее с двумя. B>1. Не в 20-50, а в 2-3.
Ссылочку я уже приводил. там указывается даже не 20-30, а 50-100 раз увеличение быстродействия.
B>2. Только в очень специальных задачах, которые идеально ложатся в рамки иерархических СУБД. А таких задач, в настоящее время, просто мизерное количество.
Весь мир иерархия. А в РСУБД это приходится притягивать за уши.
A>>Примеры можно взять из многочисленных success story например на сайте www.instersystems.ru B>Эти многочисленные SS просто детский лепет, по сравнению с количеством и объемом информации, который хранят и в обрабатывают РСУБД. B>Когда хоть какая-нибудь иерархическая база появится на tpc.org вот тогда и поговорим, а до этого времени все это не серьезно.
В характристиках Ролс-Ройсов про мощность мотора пишут — "ДОСТАТОЧНАЯ". Так что? отстойная машина?
B>P. S. B>Господа, вы забываете еще один аспект универсальности RDBMS. Информация имеет свойство хранится очень и очень долго. И сама информация переживает системы ее обработки. Благодаря тому, что в/из реляционную структуру можно перевести данные любой сложности — нет никаких проблем обработки реляционных данных многолетней давности, собранных в системах о которых мы даже не знаем. Все же остальные модели, в том числе и иерархическая предполагают некоторую зависимость способа хранения данных от самих данных, и когда со временем данные потребуется представить в другом виде это потребует серьезного перестроения модели хранения этих данных.
Вот, вот... Та же Intersystems на рынке уже более 25 лет... и обеспечивает между все продуктами совместимость.
B>А реляционная модель подобным мутациям не подвержена.
Ввиду своей мутационности изначально....
прошу не обижаться. ну ОЧЕНЬ не люблю реляционную модель.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Пусть будет так. И каковы затраты на запись. Давай посчитаем 20ГБ в сек скорость записи не самого хорошего диска. Сколько данных в секунду записывается в реальной базе????? S>> За весь рабочий день столько не наберется. M>Не правильно считаешь. 20 Гб пишется за раз, а тут скидываются и поднимаются странички в среднем 8К размером. Да еще в разных частях диска. Так что о 20 Гб можешь забыть. M>Тебе не зря ведь приводили стоимость дисковых операций по сравнению со всеми остальными...
Тфу 20МБ. Это скорость чтения записи по байтам.
S>> И как они еще ворочаются. 20ГБ в сек значит предел для них. А вы тут SQL SQL. M>Да. занимательная у тебя получается арифметика.
Ну ошбся в тыщу раз 20МБ
S>> То есть если страницы в памяти то они все равно каждый раз считываются с диска???? M>Нет конечно, но все страницы не с кешируешь.
А их много и не надо только к частобращаемым а обычно это актуальные остатки справочники итд которые легко помещаются даже в обычный объем памяти. Для других задач есть ОЛАП итд.
S>> Запись в БД занимаю небольшие затраты по сравнению с чтением. M>Не большие, но вполне заметные.
Так разговор на данном этапе даже не о записи а о чтении и расширенной организации данных. Вы Синклеером говорите что ООП на стороне сервера это тормоза, а я что нет и даже во многих случаях выигрышь. А нужна прежде всего гибкость и скорость разработки а не за сколько выполнится тот или иной запрос. ECO, OBjectSpasec на сторону сервера!!!!!
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Но при объеме памяти больше чем БД на подкачку время не будет тратится. S> А по поводу 10 человек то просто с синхронным чтением и записью на откомпилированных выборках и записях это вообще не заметно, т.к. глобальные выборки делаются редко а все остальное занимает милисекунды меньшее чем посылка пакета по сети которые становятся в очередь.
По этому поводу есть анекдот хороший...
Смотрит медведь на бегемота, час смотрит, два, три... Наконец бегемоту это надоедает он и говорит:
— Ну чего уставился?
— Да вот думаю, таким бы хлебальцем, да медка бы навернуть!
Мы уже победили, просто это еще не так заметно...
На самом деле — получение инструмента, которые позволяет так ускорить разработку даже при небольшом понижении производительности — уже круто. Так что я, в общем, впечатлен. Будем исследовать опыт передовиков OLTP — производства!
