Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 73 74 75 76 77 [78] 79 80 81 82 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31627
CREATE TABLE S(I INTEGER,J INTEGER,V INTEGER, PRIMARY KEY (I,J))
SELECT I,SUM(V) FROM T GROUP BY I ORDER BY 1

На М примерно так будет?
s (I,J)="" k ^R
f s I=$o(^S(I)) q:(I="") d
. f s J=$o(^S(I,J)) q:(J="") s ^R(I)=^R(I)+^S(I,J)
f s I=$o(^R(I)) q:I="" w I," ",^R(I),!

А как записать на M
SELECT I,SUM(V) FROM T GROUP BY I ORDER BY 2
?
8 янв 07, 17:52    [3613572]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
С другой стороны - в Каше есть возможность манипулировать ростом глобалов - что по идее выражается в разбросанности "связанных" блоков на диске.


Это не поможет

Ptn

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


Возможно для Вас сюрпризом будет узнать что существует такая вещч как Ad-Hock (нерегламентированные) запросы. Возможно это будет сюрпризом и для того кто проектирует ВСЕ возможные запросы на этапе проекьтирования, но это уже будет проблема того, кто нанял его на работу.

До свидания, домой пора
8 янв 07, 17:54    [3613575]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
> Да, и какие накладные расходы будут у пишущей транзакции Вы так и не огласили.

никаких

пока пишущая на сервере транзакция в программе на м-клиенте выглядела так:

TStart
s ^MyBase("2007")=10
s ^MyBase("2006")=20
TCommit

мне даже непонятен вопрос
8 янв 07, 18:03    [3613595]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
Ptn
Lepsik>>кол-во строк сравнивать смешно - я читаемость считаю немаловажной.
Про что и речь. Но ведь нам предлагают именно это .


Ptn
>>сравнивать надо исполнимый код.
Вот вот - где в вашем коде доступ к данным ?


вы тогда определение данных дайте, а то я всегда считал считал - то что в переменной и есть данные.

>>ну а сравнивать интерприруемые языки с компилируемым - это даже не смешно.
Осталось найти этих юмористов. ;)

да их тут полный тред. У меня и сомнений не было что С++ в 10-100 а то и быстрее раз быстрее чем языки типа М

>>Тем более что в DB2 он по жизни был чуть ли единственным средством программирования
--А в Cach'e он один из многих и что ?

Тут я уже совсем запутался. Апологеты утверждают, что в М - единственный встроенный язык в Каше, а реляционщиков TSQL/PL/SQL - и он куда хуже, то наоборот. Вы между собой для начала договоритесь.

Сухой остаток - С++ быстрее, понятнее для понимания, а в силу настраиваимости я легко синтаксис в нем перестроить добавлением файла описаний - и писать на нем хоть как на M/Каше/Perl/Lisp/Prolog/Basic/Pascal/PHP.... остальное добавить по вкусу.
8 янв 07, 18:31    [3613642]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
vadiminfo>> А если про Юзеров, то можно вспомнить, что кроме SQL есть еще реляционный язык БД QBE (там бланк запроса заполняют) и туча тулс для генерации отчетов.

Ничего не имею против. есть.

>>Да и скриптовых готовых языков полно. XML, например. Он тоже лидирующий среди скриптовых и его тоже поддерживают РСУБД и не только.
Ну видимо и Каше тоже

Он сначало должен быть SQL - сервером, а потом можно говрить об ODBC и прочих средствах доступа из клиентов к серверу. Пока мы знаем, что он внедрил SQL - другой способ доступа из прог к SQL - серверам. Т.е. это значит, что на нем можно писать клиентские проги к настоящим
SQL серверам.

Да можно

>> Т.е. поддерживает он РМД или нет.
Да поддерживает за процент поддержки не скажу - ибо слова слишком общи.

>>Если на нем как на С можно самому налабать поддержку РМД, то это тулса для разработки СУБД.
Можно - именно так и сделано вся SQL это надстройка на М.

>>Но Вы сказали нет.
Я имел в виду что не как на С-и.

>>Тогда он должен поддерживать реляционные таблицы.
Да

>>Реляционные органичения целостности.
С оговорками - для отношений поддерживает для ключей нужно доп программирование

>>Не совсем так. Но вот мы с Вами пытаемся прояснить насчет одного из важнейших аспектов сравнения - МД.
Не уверен. Мне почему то порой кажется что вы просто хотите услышать что М это не СУБД.

>>И кстати, зачем тогда они сравнивают М с SQL, если М тоже типа РСУБД?
Потому что нет никакого смысла сравнивать SQL c SQL IMXO

>>Что это значит? Что мнением тех парней, что не довольны стоит принебреч?
НЕТ - это значить что я не вижу смысла обсуждать тут данный вопрос.
Ну или давайте подумаем как относяться SysBase-вцы вроде да ? к MS-SQL - и кому это вообще интересно.

>>Первая Ваша фраза означает, что М не ООМД.
Не совсем ясно как язык может быть моделью данных. Он либо позволяет её использовать либо нет.

>>А вторая фраза означает что в М есть любая МД и стало быть ООМД среди прочих любых.
Мое мнение что да. CDL - с полной атрибутикой (указание классов, наследования, полиморфизма и т.д.) и реализующая ООМД - и класс хранения обеспечивающий МД написан именно на М.

>>Поэтому эти две фразы без дополнительных разяснений выглядят как противоречащие друг другу.

Я пояснил выше. Дело в том что вы как то уперлись именно в М. В Каше есть Class Defitininon Language через него SQL далее Cache Script Rules, Cache Script Pages и даже BASIC и всё это построено на М. А SQL получается сразу построен при помощи классов.

>>Она должна превзойти в одиночку, либо в группе подобного типа СУБД реляционные СУБД, более того ОРСУБД. Стать доминирующей в ИТ.
А вот с этим извините решительно не соглашусь ?
Эдак мы скоро договоримся до того что если 3Д-шутер не побил рекордов продаж, то он, увы, 3Д-шутером не считается.

>>Я говорил Вам про сторонников Версанта, которые не отнесли Кашу к ООСУБД.
Я помню - вы помните что я на сей счет сказал ? Всегда есть нюансы - всегда есть порог.

Кто то видишь шакаладку и говоровить - о шаколадка. А кто то берет этикетку и говорит - блин тут содержание какао на 3% меньше. И что делать ?
Мне неизвестны критерии Версанта - но вполне допускаю что какому либо критерию Каше не соотвествует. Значить ли что эти критерии единственно возможные ? - сомневаюсь ;)

>>Заметьте - популярнее М. Откаты?
Нет - слова есть такие доступность и распростаненность.
Причина популярности виндовс кроется в популярности виндовс (С) Acceler

>>Но мы то про все случаи из применения БД в ИТ?
Наврятли - на всё случаи одной БД не бывает IMXO

Ну не о том, что лучше PL/SQL или М. Пока о том что РСУБД лучше М. Т.е. SQL + PL/SQL (или другое расширение - у СКуля T-SQL, по моему) для БД и + современные языки для клиентов и серверов приложений лучше ИС на М.
А в дальнейшем не спорим, а пытаемся прояснить как соотностятся MSSQL и Каша.


Еще раз ... никто не мешает писать используя C,C++,Deplhi,.Net,Java,любой язык + ActiveX, HTML+JS, XUL и в скором времени видимо XAML

>>Для начала хотелось бы прояснить про каждый из квадратов куба. Если он РСУБД, то это можно отдельно прояснить. Каков, например, там диалект SQL и все такое. Что на нем можно.

Соотвествует вроде SQL-92, есть ограничения - на процедуры, который периодически задают специалистам ISC.
Видимо от того что для реализации циклов и условий достаточно М.
Вот тут подробнее

>>Должен позволять создавать все обекты БД, юзеров БД, управлять ими, извлекать инфу (включая системную), изменять ее.
Э-э-э М ? то есть COS ?
Добавление триггера
Set cname="SUPER_PUPER_CLASS"
Set cl=##class(%ClassDefinition).%Open(cname)
If cl="" Write "Couldn't open Class ",cname Quit
W !,"Processing Class "_cname

//now add another trigger
set tref=##class(%Library.TriggerDefinition).%New(cname_".Trig1")
set tref.Name="trig1"
set tref.Event="INSERT"
set tref.Time="BEFORE"
// трассируем изменения
set tref.Code=" set ^drltrace(trigcnt)=$h"
set sc=cl.Triggers.Insert(tref)
w !,"Inserting trigger sc=",sc
set sc=cl.%Save()
w !,"Saving trigger sc=",sc

>>Не должен позволять ничего не связанного с управлением БД, например, писать драйверы.
Драйвер увы ...

>>А Вы вроде признали где-то, что специализированный как правило лучше подходит для того на чем он специализируется, чем не специализированный. Поэтому и не ясно.

Тем что он не существует вне СУБД
8 янв 07, 18:31    [3613643]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
frutalino
мне даже непонятен вопрос

То, что необходимо подерживать копии фрагментов на узлах в согласованном состоянии.
То, что все узлы должны будут зафиксировать транзакцию, даже если копии у них находятся только в памяти.
То, что вся эта байда должна управляться с сервера, иначе бардакс будет.
То, что сервер это будет делать по той же несчастной сети используя (кстати какой?) протокол фиксации транзакции.
А мы же помним, что на каждый узел по 390КБ в секунду в этой сети-то приходится. А узлов-то 256. А пакеты по сети туда-сюда-туда-сюда. И сколько транзакцию в секунду будет в такой системе выполняться? Одна? Две?
8 янв 07, 18:33    [3613645]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan)>>Поскольку всего этого благолепия в Cache нету, то и ROWID-ов быть не может. Говоря про ROWID-ы я совсем не имею в виду ручную нафигация, как Вы могли подумать

>>Замечтательно коли так, но какова будет стоимость разработки этого велосипеда ?
Блогодоря ООП небольшая. Тем более я хотел бы обратить внимания что всего этого якобы нет в принципе - то есть невозможно.

>>В целом ваша позиция ясна (с)
>>Но так можно от всего поотказываться :)))

Не нужно отказыватся от всего - но и молотки не нужно определять по наличию гвоздодёра.

>>Второе весьма сомнительно, скорее всего чтение будет поблочное, причина оглашена выше
This command reads the sixth block from the Caché database into the View Buffer.
   VIEW 6
This command writes the view buffer back to the sixth block of the Caché database, 
presumably after the data has been modified.
   VIEW -6
This command copies the string "WXYZ" into four bytes starting at absolute location ADDR. 
The expression $VIEW(0,ADDR,-4) would then result in the value "WXYZ" .
   VIEW 0:ADDR:-4:"WXYZ"
число 6-ть реализует многоблочное чтение, а ADDR в легкую превращается в ROWID.

Вот вам концепт - того чего у нас не может быть по определению ;)

>>Это НЕСОМНЕННО перл. Теперь я знаю что такое ООП :)))

Да пожалусто - мне не жалко. Кто ж вас знает что у вас на уме.
8 янв 07, 18:41    [3613658]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Изопропил
CREATE TABLE S(I INTEGER,J INTEGER,V INTEGER, PRIMARY KEY (I,J))
SELECT I,SUM(V) FROM T GROUP BY I ORDER BY 1

На М примерно так будет?
s (I,J)="" k ^R
f s I=$o(^S(I)) q:(I="") d
. f s J=$o(^S(I,J)) q:(J="") s ^R(I)=^R(I)+^S(I,J)
f s I=$o(^R(I)) q:I="" w I," ",^R(I),!

А как записать на M
SELECT I,SUM(V) FROM T GROUP BY I ORDER BY 2
?

Ну примерно так.
 set z="^S" k ^mtempZ
 for  { set z=$query(@z) quit:z=""  set j=$i(^mtempZ("I1",$qs(z,1)),$qs(z,2)) }
 set i="" for  { set i=$o(^mtempZ("I1",i)) quit:i=""  set ^mtempZ("I2",^mtempZ("I1",i))=i }
 set j="" for  { set j=$o(^mtempZ("I2",j)) quit:j=""  write ^mtempZ("I2",j)," = ",J }
8 янв 07, 18:54    [3613677]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
Локшин Марк
frutalino
мне даже непонятен вопрос

То, что необходимо подерживать копии фрагментов на узлах в согласованном состоянии.
То, что все узлы должны будут зафиксировать транзакцию, даже если копии у них находятся только в памяти.
То, что вся эта байда должна управляться с сервера, иначе бардакс будет.
То, что сервер это будет делать по той же несчастной сети используя (кстати какой?) протокол фиксации транзакции.
А мы же помним, что на каждый узел по 390КБ в секунду в этой сети-то приходится. А узлов-то 256. А пакеты по сети туда-сюда-туда-сюда. И сколько транзакцию в секунду будет в такой системе выполняться? Одна? Две?



ну не знаю - это все давно придумано
вот именно то, что вы перечислили, поддерживается специально созданным для этой цели супер-пупер протоколом - ECP - Enterprise Cache Protocol

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

Ваши переживания про "несчастную сеть" удивляют.
Именно "несчастная сеть" устойчива к сикам и делает "счастливой" дисковую систему.

дисковая система имеет ярко выраженный порог возможностей механических устройств.
А сеть - это же транзисторы, там ничего не крутится и не вертится.

Если сеть захлебнулась - надо переконфигурировать м-клиенты.
Мне интересно, а что вам удасться переконфигурировать, когда винты "кластера" встанут от сиков, да ничего (причем за любые деньги).
8 янв 07, 19:19    [3613702]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Ptn
Выбегалло>>ну показывайте.
Ну читайте - тут вам и про Хеш и про многое другое


Почитал. Проникся. Оказывается, для того, чтобы эффективно программировать на MUMPS, надо быть напроловину разработчиком движков баз данных. Все, за что в РСУБД уже заплачено - индексирование, к примеру - в M надо писать самому.

Ptn
>>В том то и дело, что "в упрощенном виде". Ну очень упрощенном.

Уважаемый - а мне и нужно в упрощенном.
В неупрощенном использую SQL + модификатор %FULL и не парю себе голову - пусть оптимизатор БД планы перебирает.
С той лишь разницей что я всегда могу посмотреть чего он там сделал и сделать компиляцию из нескольких ЕГО вариантов.


Уважаемый, вы не сталкивались с настоящими оптимизаторами. И настоящими запросами. Там количество вариантов плана идет на миллиарды.

Кроме того, оптимизатор ценен тем, что позволяет менять план динамически - в зависимости от статистики индексов, таблиц, и много чего. А что можете вы ? В лучшем случает - написать его жалкое подобие, "если в таблице А меньше ста трок, использовать индекс 1, иначе - индекс 2". В 99.9% случаев и этого никто из М-программистов не делает, потому что не тот уровень.

Ptn
>>Название доки, номер страницы ?
Вы не поверите - дока на сайте ISC


Так дока-то ваша - по SQL , однако ! Прямой доступ, выходит, это хорошо - но как до дела доходит, когда транзакции потребовались - то начинаете SQL использовать ? Ну и нахрена мало-мальски трезвому программисту учить два языка (M и SQL), вникать в детали физического хранения индексов, ловить баги блокировок - когда можно взять нормальную РСУБД и не париться ?
8 янв 07, 20:13    [3613757]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
))
Guest
Sergei Obrastsov
Ну вот, посмотрел я, значит. Итак, 8k транзакций, заметьте, не 1k запросов, локально, на машине 1.6Ghz/1Gb и вся БД в RAM, они даже время выделяют на ее "warm up", сиречь засовывание туда.
Прекрасно, даже и тексты есть. Ну так я не поленился сделать аналогичный тест в Cache.
Без фиксирования БД в памяти, правда, конечно, расширив кэш до аналогичных размеров, то есть 350 Mb. Итог: 18.1k tps. Машинка примерно такая же 1.8Ghz/1Gb, домашний комп, не $2k конечно,
подешевше. Все-таки лучше говорить о запросах в секунду.

ну, у него там ноут 2кг, 12 дюймов, а под картинкой написана цена вашего домашнего. 2.5tps в одном потоке, 8.3tps в восьми. что такое "запрос" кстати? тексты приведены, графики нарисованы... откуда Итог? не стесняйтесь, я все равно ничего не пойму :)
8 янв 07, 20:22    [3613765]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
frutalino
Локшин Марк

А давайте теперь посчитаем. Ну пусть у Вас там даже оптоволокно. Итого общая пропускная способность ~100МБайт/с - т.е. в районе скорости линейного чтения ОДНОГО современного винтчестера . . .



с чего вдруг Вы взяли, что 100МБайт/с - это скорость "ОДНОГО современного винтчестера"?

если будет 500 сиков/секунду винчестер не сможет считать даже 1 мегабайт за час, он вообще перегреется и заклинит,
это же механическое устройство

но опять же это версия, а не утверждение


Фруталино, я вам по-дружески советую : перестаньте позориться. Доучитесь курса хотя бы до третьего.
8 янв 07, 20:32    [3613771]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
frutalino
>>
инструментарий в принципе позволяет логически управлять сиками, к примеру с веба, направляя их на нужные М-клиенты, в которых уже есть нужные куски М-базы

веб-юзеры не будут даже доходить до сервера, роль которого в концепции масштабирования уменьшается до писателя транзакций и read-старт-up загрузчика М-клиентов

итак мы приходим к Google–моде на sempron-ах.



Данная модель называется "shared nothing" архитектура и уже много лет реализована в Informix XPS, Teradata, DB2 EEE. Серьезными дядями в больших корпорациях. Те же много лет известно, что главное западло этой модели в требованиях к пропускной способности межмашинной связи, из-за чего Терадата , например, использует собственный коммуникатор. Возвращаемся к предыдущему тезису : MUMPS - это набор "сделай сам".
8 янв 07, 20:45    [3613783]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
frutalino
ну не знаю - это все давно придумано
вот именно то, что вы перечислили, поддерживается специально созданным для этой цели супер-пупер протоколом - ECP - Enterprise Cache Protocol

А вот Вы попытайтесь понять, что там есть.
Хорошо, читаем вместе, что про это написано на сайте Intersystems:
http://www.intersystems.com/cache/technology/components/ecp/index.htmlДавайте разберем, что там написано, если это так сложно.
InterSystems
InterSystems' Enterprise Cache Protocol is designed to dramatically enhance the scalability and performance of distributed applications. Optimized for thin-client architectures, Enterprise Cache Protocol makes network traffic between application servers and the database more efficient, thus allowing the network to support an expanded middle tier and more users

Да, увеличивают производительность. За счет чего? Тонких клиентов + серверов приложений. Ага, кажется про трехзвенную архитектуру никто ничего не говорил до сих пор. Не правда ли?
Читаем дальше.
InterSystems
The days of "thick-client" distributed architectures are waning. With the widespread and ever-growing adoption of Internet technology, the "client" piece of most client/server architectures is very likely to be a Web browser. Most of the processing load is handled by application servers, which are often large machines with lots of memory. One key to building fast, scalable solutions for today's thin-client architectures is to take advantage of the power of these machines, and reduce the amount of network traffic between application servers and data servers.

Стоп-стоп-стоп. large machines with lots of memory - это надо понимать Sempron и есть, да? Ой, а в AMD то и не знают, надо будет наверное дуракам этим написть, а то на халяву продают.
Дальше немного пропустим и перейдем к заключительному абзацу, т.к. выше повторяется буквально тоже самое что и в нем.
InterSystems
With ECP, requests to the Cache data server are answered with more than just the requested data - building up shared caches of relevant data. Data cached on the application servers can be used to satisfy subsequent requests from any client connected to that server. Performance is increased because clients often use data cached on the middle tier. Also, there are fewer calls to the data server, so network traffic is reduced, which means the network can support more applications servers, and thus more clients.

Здесь идет описание того, как будет все круто. Почему-то считается, что запросы должны попадать в закэшированные на узле данные. Ну допустим. А как они (данные) туда должны попасть? Не по той же сети? А если запрос и ответ 100 байт занимают, а данных гигабайт перелопатить нужно. Что будет быстрее?
К сожалению из этого описания не ясно, как будет себя вести сервер приложений, если данных в кэше не оказывается - пытается затянуть их в себя и потом только выполняет запрос, или действует более разумно. Если первое, то во многих случаях это приведет к ухудшению производительности вместо увеличения.
В любом случае, ставьте в параллель несколько серверов БД, реплицируйте между ними базы и получайте тоже самое, и даже еще больше. Тут, пока я писал и про TeraData Вам уже сказали, да и у других тоже есть средства и у Oracel и у MS SQL.
Обратим внимание на последнее предложение:
InterSystems
so network traffic is reduced, which means the network can support more applications servers, and thus more clients.

Вам, господин любитель транзисторов, дословно перевести или сами справитесь? Производитель говорит, что узким местом является СЕТЬ, а не дисковые массивы. Надеюсь Вы ему больше чем мне верите?
Теперь общее замечание. Это все относится к проблеме разнесения нагрузки большого числа пользователей небольшими запросами/транзакциями. К проблеме использования нескольких процессоров, дисков, узлов для исполнеия одного запроса это никакого отношения не имеет.
Задание на дом: прочитать про протоколы фиксации распределеных транзакций и подумать, откуда там берутся большие накладные расходы и что будет с системой на 256 Sempron'ах например при 100 пишущих транзакциях в секунду.
8 янв 07, 21:05    [3613802]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло Почитал. Проникся. Оказывается, для того, чтобы эффективно программировать на MUMPS, надо быть напроловину разработчиком движков баз данных. Все, за что в РСУБД уже заплачено - индексирование, к примеру - в M надо писать самому.
Ну значить так читал - чтение и толкование вслух извини платное.

Кроме того, оптимизатор ценен тем, что позволяет менять план динамически - в зависимости от статистики индексов, таблиц, и много чего. А что можете вы ? В лучшем случает - написать его жалкое подобие, "если в таблице А меньше ста трок, использовать индекс 1, иначе - индекс 2". В 99.9% случаев и этого никто из М-программистов не делает, потому что не тот уровень.

Опа - нада же я тот самый 0.01% Оценил-оценил :)))) Читать раздел Dynamic SQL до просветления.
Вслух извини платное.

>>Так дока-то ваша - по SQL , однако !
ДА ВЫ ЧТО ? Бес попутал однозначно. А ссылку на Language Bindings вообще давать страшно - вдруг еще какие открытия совершите

>>Прямой доступ, выходит, это хорошо - но как до дела доходит, когда транзакции потребовались - то начинаете SQL использовать ?

Я ж говорю - значить так читал.
Вот объясняешь объясняешь им про тройственный доступ - они всё по старинке либо туда либо сюда - ну никакой жизни. SQL для транзакций даже компилятор каши не использует.

Ну и нахрена мало-мальски трезвому программисту учить два языка (M и SQL), вникать в детали физического хранения индексов, ловить баги блокировок - когда можно взять нормальную РСУБД и не париться ?

Нафиг не нужно - а вы что не знали что ли ?
Ведь нормальные программисты они того - они не могут иначе .
Их и PL/SQL то из под палки заставляют учить - а тут вообще туши свет.

[смахивает слезу умиления] Где ж ты мало мальский трезвый программист - со знанием чистого и единственного SQL???
8 янв 07, 21:23    [3613819]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Локшин Марк
Да, увеличивают производительность. За счет чего? Тонких клиентов + серверов приложений. Ага, кажется про трехзвенную архитектуру никто ничего не говорил до сих пор. Не правда ли?
Читаем дальше.


Не оправдывая легкий бред "сторонника" про замечательную "сеть" хочу еще раз заметить - нет никаких [+ серверов приложений] Каждая копия Каши это Сервер БД и Приложений в одном флаконе.

К сожалению из этого описания не ясно, как будет себя вести сервер приложений, если данных в кэше не оказывается - пытается затянуть их в себя и потом только выполняет запрос, или действует более разумно.

Недавно у нас в разделе подобный вопрос поднимался - если интересно зайдите.
8 янв 07, 21:29    [3613826]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Ptn
Не оправдывая легкий бред "сторонника" про замечательную "сеть" хочу еще раз заметить - нет никаких [+ серверов приложений] Каждая копия Каши это Сервер БД и Приложений в одном флаконе

Инакобродствуете против текста и картинок InterSystems. Зайдите по ссылке. Они это дело не так позиционируют.
8 янв 07, 21:53    [3613854]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Локшин Марк
large machines with lots of memory - это надо понимать Sempron и есть, да? Ой, а в AMD то и не знают, надо будет наверное дуракам этим написть, а то на халяву продают.

напишите. они любят читать спам от остряков и подобный поток сознания.
Наблюдая за всем этим проникаешься уважением к сторонникам MUMPS, видимо все таки более взрослые и состоявшиеся люди
8 янв 07, 21:57    [3613857]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Локшин Марк
Ptn
Не оправдывая легкий бред "сторонника" про замечательную "сеть" хочу еще раз заметить - нет никаких [+ серверов приложений] Каждая копия Каши это Сервер БД и Приложений в одном флаконе

Инакобродствуете против текста и картинок InterSystems. Зайдите по ссылке. Они это дело не так позиционируют.


Вообще то нет - просто никто не запрещает использовать сторонние сервера приложений - на том же EJB

А учитывая что на картинке собсно названия продуктов не подписаны - только функции квадратиков обозначены. Поясняю что Shared Cache это локальный кэш копии Cache в режиме ECP клиента - вот здесь текста больше, не на картинках правда
8 янв 07, 22:14    [3613872]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
Локшин Марк

Здесь идет описание того, как будет все круто. Почему-то считается, что запросы должны попадать в закэшированные на узле данные. Ну допустим. А как они (данные) туда должны попасть? Не по той же сети? . . .

Обратим внимание на последнее предложение:
InterSystems
so network traffic is reduced, which means the network can support more applications servers, and thus more clients.

Вам, господин любитель транзисторов, дословно перевести или сами справитесь? Производитель говорит, что узким местом является СЕТЬ, а не дисковые массивы. Надеюсь Вы ему больше чем мне верите?


такой литературный перевод - я торчу
вообще-то здесь не написано, что узким местом является сеть

здесь написана логика работы Cache по ECP:
1 сервер данных может поддерживать до 256 серверов приложений
все запросы идут через сервера приложений
у каждого сервера приложений - свой кеш, в который медленно, как вы совершенно правильно заметили, но верно, заливаются данные с сервера данных по запросам юзеров

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

кстати, попытка задать вопрос по производительности ECP приводит примерно к такому ответу - "а он вас что не устроил? вы вот попробовали - и у вас захлебнулась сеть?" :-)

мне нравится такой ответ - и правда, надо попробовать вначале
чего переживать-то
тут не о чем переживать
8 янв 07, 22:55    [3613915]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Ptn
Выбегалло Почитал. Проникся. Оказывается, для того, чтобы эффективно программировать на MUMPS, надо быть напроловину разработчиком движков баз данных. Все, за что в РСУБД уже заплачено - индексирование, к примеру - в M надо писать самому.
Ну значить так читал - чтение и толкование вслух извини платное.


По данному вопросу слив защитан.

Ptn
Кроме того, оптимизатор ценен тем, что позволяет менять план динамически - в зависимости от статистики индексов, таблиц, и много чего. А что можете вы ? В лучшем случает - написать его жалкое подобие, "если в таблице А меньше ста трок, использовать индекс 1, иначе - индекс 2". В 99.9% случаев и этого никто из М-программистов не делает, потому что не тот уровень.

Опа - нада же я тот самый 0.01% Оценил-оценил :)))) Читать раздел Dynamic SQL до просветления.
Вслух извини платное.


Жалкое подобие оптимизатора написали ? Ай, маладца ! Есть чем выделиться на фоне безрадостной массы прочих мумпсятников.

Ptn
>>Так дока-то ваша - по SQL , однако !
ДА ВЫ ЧТО ? Бес попутал однозначно. А ссылку на Language Bindings вообще давать страшно - вдруг еще какие открытия совершите


И по данному вопросу слив защитан.


Ptn
>>Прямой доступ, выходит, это хорошо - но как до дела доходит, когда транзакции потребовались - то начинаете SQL использовать ?

Я ж говорю - значить так читал.
Вот объясняешь объясняешь им про тройственный доступ - они всё по старинке либо туда либо сюда - ну никакой жизни. SQL для транзакций даже компилятор каши не использует.


Достаточно одному Васе воспользоваться прямым доступом к данным, и вся ваша ACID накроется пилоткой. А как пишет ваша же дока, "Caché ObjectScript transaction processing, using TSTART and TCOMMIT, differs from, and is incompatible with, SQL transaction processing using the SQL statements START TRANSACTION and COMMIT."

Ptn
Ну и нахрена мало-мальски трезвому программисту учить два языка (M и SQL), вникать в детали физического хранения индексов, ловить баги блокировок - когда можно взять нормальную РСУБД и не париться ?

Нафиг не нужно - а вы что не знали что ли ?
Ведь нормальные программисты они того - они не могут иначе .
Их и PL/SQL то из под палки заставляют учить - а тут вообще туши свет.


И по данному вопросу слив защитан. Доводов в пользу изучения 2 языков не предоставлено. Кстати, "тройственный доступ" - из той же серии. Нахрена ?
8 янв 07, 23:17    [3613939]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
frutalino

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


все это замечательно и все такое, но как они поддерживают согласованность копий данных ?
8 янв 07, 23:22    [3613942]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Sergei Obrastsov

Ну вот, посмотрел я, значит. Итак, 8k транзакций, заметьте, не 1k запросов, локально, на машине 1.6Ghz/1Gb и вся БД в RAM, они даже время выделяют на ее "warm up", сиречь засовывание туда.
Прекрасно, даже и тексты есть. Ну так я не поленился сделать аналогичный тест в Cache.
Без фиксирования БД в памяти, правда, конечно, расширив кэш до аналогичных размеров, то есть 350 Mb. Итог: 18.1k tps. Машинка примерно такая же 1.8Ghz/1Gb, домашний комп, не $2k конечно,
подешевше. Все-таки лучше говорить о запросах в секунду.
Так tps или qps?
8 янв 07, 23:43    [3613969]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
V52

Просьба к Выбегалло: - Когда будете демонстрировать своего кадавра, то, пожалуйста, в полный рост и с приложением выходного файла (результаты для 500 первых строк).
Ко всем остальным - то же самое.
Плюс укажите время выполнения и характеристики компутера.



Попробуйте выложить ваш файл еще раз. gzip -d проходит молча, но после него tar ругается
tar: This does not look like a tar archive
tar: Skipping to next header
tar: 501 garbage bytes ignored at end of archive
tar: Error exit delayed from previous errors

А в самом файле IN.tar всякая фигня содержится.
8 янв 07, 23:43    [3613970]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
Выбегалло
frutalino

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


все это замечательно и все такое, но как они поддерживают согласованность копий данных ?



мне ничего не остается предположить, что там именно она и работает - идентификация, навигация и семантика

логические блоки данных на диске - логические блоки данных в озу - остается добавить в каком именно озу - и измененный блок видимо надо перезагрузить

> Уважаемый, вы не сталкивались с настоящими оптимизаторами. И настоящими запросами. Там количество вариантов плана идет на миллиарды.

мне почему-то кажется, что не долго осталось нам ждать настоящих запросов :-)
кстати недавно на RBC меня поразило интервью одного из директоров Google - он так и сказал про прогнозы - мол х%йня это все - сеть, куча сетевых компьютеров - а гланое - это мейнфрейм - вот за этим будущее :-о :-)
дошло до дяди
дореплицировался
8 янв 07, 23:44    [3613973]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 73 74 75 76 77 [78] 79 80 81 82 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить