Newsgroups: intersystems.public.cache で、Cache'(db)の使い方について深く議論したスレッド
Subject: newbie questions (新参者の質問)
があります。とても長くなり恐縮ですが参考になりますので要点を書いて、原文をポストします。
Oracle, Sybase, MSSqlの経験者のRayさんという方が、Cache' dbを数日使った後、過去のこのNewsgroupsの内容と、devconのプレゼン資料
(多分 http://
を読み、Cache'に大いに興味を持ち、質問をしたところから始まります。
No.1 Ray Zhangさんの 12 の質問
-------------------------------------------------------
1) 対話型DML(Data Manipulation Language)があるか?
2) 端末モードが初心者にアンフレンドリー
3) Oracleよりなぜ 5-20倍早いかの説明、どんなテストでの比較か？
Cache'の設計思想は?
昼夜いずれの処理でも上の性能差が出ることの説明が、B-treeとSparse array だけでなぜ出来るのかが分からない
Cache'にはそれ固有の弱点があるはずだが、ないのか？
4) Python bindingのもっと説明を
5) CSP(Cache' Server Pages)はどうしてそうスケーラブルなのか？
Apacheで動いている場合、mod_jk2 や mod_perlとほぼ同様に動いているのか？
mod_perlと同様なら、Apacheのスケーラビリティに従属すると思うが?
mod_jk2 と同様なら java app serverのスペーラビリティに従属すると思うが?
6) mod_jk2と同じように動くとして、CSPはどうしてスケーラブルなのか？
app server と db server を同じに考えることは私には理解しにくい。
db serverをstored proceduresのapp serverとみなしたとしても、unix的には別々のものに思えるが?
7) shadow server は hot standby か? ジャーナル（トランザクションログ）で一方向更新のミラーサーバーがある。そうだとしたら、どうそれをスケールアップするのか？
read-only report server については語られず、むしろ real concurrencyとある？
clusteringとdistributed transactionsのサポートは?
two-phase commit は装備されているか？
8) Cache' はACID compliantか?
9) Cache'は concurrency と versioning をどう扱うか?
large transactions をどう扱うのか?
10)mysqlのように data corruption の問題はないか?
does it need to be vacuumed frequently like in postgresql?
11)ハード障害にCache'はどう対応しているのか?
12)Intersystemsの売る立場からすると、Cache'を単なるスタンドアローンDBとしてでなく、db server, app server, OO, csp, dev/design tool (uml?), etc.のセットとして売るほうが有利であるのは理解出来る。しかし、Cache'を OO機能がない他にあるRDBMSのひとつとして考える人にとって、Oracle や Sybase でなくて、Cache'を使う有利性がそこにあるのでしようか？ それとも、Cache'流の（全体セットで考える）考えを受け入れる必要性があるのでしょうか？
上手に質問出来ないので、私が聞きたいことをそちらでうまく理解してもらえるといいですが。
OO機能についてですが、objectstore や objectivity など他のoodbmsと比較してCache'はどうなんでしょうか？ Cache'は、oodbms だから、Oracleに比べ、5-20倍早いのか？ その理由は、oodbms が理論的にも Oracle よりはるかに早いはずだからか、あるいは、Cache'が他でやっていない何か特別なことをしているからなのでしょうか？
この質問を悪く取らないで下さい。誰かに挑もうとしているのではないです。
新しい製品を学ぶ時の私のスタイルなんです。
-------------------------------------------------------
なかなか真摯で突っ込んだ質問です。
この質問に対し、Cache'のOO機能支持者から非支持者まで色々な意見が続きます。
特に12)番目の質問で盛り上がります。
No. 3
M,DSM,Cache'で約15年の経験のあるDennis Coxさんが12の質問に適切に答えています。
-------------------------------------------------------
12) Cache is faster even if you don't use the native object storage but use "old-style" global access. Even with objects, the data is stored in objects, it is just that there is a set of wrapper routines that allow the SQL and object access to the data without knowing the global structure.
-------------------------------------------------------
No. 4
Ramさんが追加で答えてます。
-------------------------------------------------------
> 3) cache must have its own weak spot, no? :)
Many weak spots but don't look for them performance wise.
Intelligent caching and delayed writes have a lot to do with the massive performance gains. But IMHO neither would be possible without the underlying B-tree structure.
> 6)
It's a lot like mod_jk2...
...and Cache'(CSP) scales extremely well but the default licensing model is certainly not amenable to public Web applications (there are special licenses for that though)
デフォルトのライセンスモデルで、CSPをパブリック（インターネット）Webアプりに使うのは適用し難い(certainly not amenable)。他に特別なライセンスもあるが。
これは、CSPではイントラネットばかりでなくインターネットでもブラウザーからCache'サーバーにセッションを張ると（処理がCache'サーバーからブラウザーに戻っても、Cache'サーバのCSPで正常なセッション終了処理がされるか、セッションタイムアウトまで）ライセンスがカウントされていることを意味しているのでしょう。
Cache Server Pages に関するよくある質問
https:/
他に特別なライセンスとは、実アクセスカウント数をベースにライセンス料を払うモデル、あるいは、最近出たRuntimeライセンス（ブラウザー・クライアント数無制限--相当高いようですが?）でしょう。
> 12)
As a "mere" RDBMS with Cache' you get a fast, scalable, stable, low maintenance solution. How's that? :)
Speed does not come from being an OODBMS. The latter benefits from the former.
-------------------------------------------------------
No. 8 Peter Cooperさんが回答追記
No. 10
David Arkellさん（OO機能批判志向）が書きます。
-------------------------------------------------------
All this is very nice in theory. Unfortunately in practise it is somewhat different. You must remember Cache is not by its nature an Object Oriented programming language. This has been grafted ontop of a totally untyped (ie everything is just a string or an array) language.
I advise you not to use the OO features, especially inheritance, any more than you have to. I have spent a couple years maintaining a system that makes extensive use of features like this and it is an absolute nightmare.
すべて理論的にはとてもいいんだか、残念ながら、実際は多少異なる。
Cache'は、本来OOプログラム言語でないことを知っておくべきだ。
完全タイプなし言語の上に接木したみたいなもので、OO機能を(必要以上に、特にインヘリタンスは)使うなとアドバイスしている。
OO機能を過度に使ったシステムを数年メンテナンスして来たが、それは悪夢だった（an absolute nightmare）。
No. 11
これに対してSukesh Hooganさん（OO機能賛成志向）が反論
-------------------------------------------------------
InterSystemsは、pure object-oriented database とは云ってない、post-relational database と呼んでいる。
I am sure you are aware of the more horrible nightmares others have in maintaining relational databases (what with fulltime & highly paid DBAs).
IMO, maintaining a Cache'based system is much easier than the RDBMSs.
もっと悲惨な悪夢はDBAのいるリレーショナルDBでもざらだ。
私見では、Cache'システムはRDBMSよりはるかに簡単だ。
My personal preference is not inheritance of the class definitions ( I do
not even use them), but inheritance & hierarchies of the data.
対Davidさんに、
May be the system you are maintaining was not designed properly, hence the
nightmare.
メンテナンスしていたシステムの設計が適切でなかったから、悪夢だったんじゃないの。
No. 12
Frank Schobさんがその二人の間に入って
-------------------------------------------------------
Sukeshさん、申し訳ないがDavidさんに同意する。
Intersystemsのマーケッティングは、the object data storage and access とそのWebサイトで言ってるよ。
あとライセンスについて触れ
I am not sure which RDBMs you mean. And I can not claim that Cache is a less expensive DBMS, especially if you need more than 200 licenses.
悪夢について
But my experience is "it depends.". As developer I must say its my nightmare too, but I earn my salary with it.
その悪夢のおかげで給料を得てる。
しかし、Sukeshさんの肯定的な経験を知ってうれしい。
最後に、Sukeshさんの大変いいCache'べースのWebサイトをほめています。
It's nice to see that your experience are more positiv. But please consider: We use Cache more as an database (with object storage and access) than as an web application development tool.And finally congratulations to your very good cache-basedc web site
http://
No. 13
DavidさんがSukeshさんに再説明
-------------------------------------------------------
That being said there are some real problems with cache classes. When you have enough classes, persistant and otherwise, cache cannot figure out dependancies propperly. I've lost count of the amount of times we had to compile the entire application because of this. And our application takes over an hour to compile.
Default storageを使うか、自分で定義するかについて
-------------------------------------------------------
You are right about the default storage. I think its pretty good too. I think the major advantage of defining your own is the ability to design your own indices. For example we have an index on username that also contains the password, kinda like this.
^UserGlobal("username-index","user@company.com",[rowID])="password"
With this method when someone tries to log into our application we can check the username/password directly without actually querying the users table. I understand that this is a small thing but its the only simple example i can think of right now.
Of course defining your own storage has its own problems but nothing is
perfect.
-------------------------------------------------------
No. 14
MUMPSで長い経験のある(I have got the grey hairs)Peter Coopesさんのコメント。
-------------------------------------------------------
David
Just a few comments
>I agree with most of what you said. Let me say from the start that I
>don't blame cache entirely for the mess i have to deal with. I think the
>initial programmers found what they thought were really nifty cool
>things they could do and just did them all regardless of whether it was
>appropriate or not.
>initial programmersはほんとにかっこいい素晴らしいと思ったこと、出来ると思ったことをそれが適当、不適かに関わらずやってしまうんです。
Totally agree - you can make some right messes - but with experience(I have got the grey hairs) you can do just the right amout of oo - ISC fell into this trap with their implimentation of streams where there was so much multiple inheritance that I for one could not undertand it
全体的には同意する。しかし、経験(I have got the grey hairs)では、OOも適度には使えます。InterSytemsは、streamsタイプの装備で私には理解できないが multiple inheritance を沢山使ってその中にはまってます。
>That being said there are some real problems with cache classes. When
>you have enough classes, persistant and otherwise, cache cannot figure
>out dependancies propperly. I've lost count of the amount of times we
>had to compile the entire application because of this. And our
>application takes over an hour to compile.
Yes this is a real pain
>And the other thing about classes. They all compile down to mac code. I
>just adds a lot of extra code to make it mimic what objects are supposed
>to do. This affects performance dramatically. The more I program
>directly at the mac level the less time I have for classes.
my rule of thumb is that object access is around 10 times slower than raw access - but have a look at embedded SQL - this can be around 2 times slower than raw access for simple operations but when you get to a comlex insert/update there seems to be little difference between embedded SQL and raw access
-------------------------------------------------------
ここ興味深いですね。
Object access は Raw access(Pure MUMPS グローバルアクセス）に比べ約１０倍遅い。Embedded SQL は単純な処理なら、Raw accessに比べ２倍ぐらい遅いが、複雑なinsert/updateでは Embedded SQL と Raw access はあまり差がない。
-------------------------------------------------------
>You are right about the default storage. I think its pretty good too. I
>think the major advantage of defining your own is the ability to design
>your own indices.
The problem I have with this is that you cannot use bit map indices and these are a real performance boost
>For example we have an index on username that also
>contains the password, kinda like this.
>
>^UserGlobal("username-index","user@company.com",[rowID])="password"
but you can define exactly this structure with objects
objectsでも同じこと出来ますよ。
No. 15
Sukesh HooganさんからFrankさんへ
-------------------------------------------------------
Frank
It has been illuminating discussion so far (that is one of the objectives of such forums).
>And I can not claim that Cache is a less expensive DBMS, especially if you need more than 200 licenses.
Now I would not be able to comment on it. InterSystems is so paranoidly secretive about its pricing model.
InterSystemsは、価格モデルについて、偏執的に秘密主義です。
I only said superb perforamnce, did not say better than custom storage. Having said that, I am loathe to change Cach・s default settings /parameters / design, as I believe with these defaults, Cach・performance is optimal (nobody knows Cache' better than InterSystems and they set the defaults).
私は、デフォルト(storage)を信じます。それを変更する気にはなれない。
Cache'の性能は、デフォルトで最適化されいる（誰もInterSystemsよりCache’を知っている人はいないのだから）
No. 16
最後にSukesh Hooganさんから議論した３人宛てに次の様に収めた。
-------------------------------------------------------
Frank, David & Peter
What I was trying to say that no DBMS is perfect (in fact, there is no such thing as perfect software), each one has it own sets of glitches, bugs and what have you and then there are its positives.
Yes, we all sometimes do try to do things/incorporate code that are/is cool but not appropriate, just to tell oneself "What a clever chap I am"
Hence I use a combination of all three - Object Access / Direct and SQL.
-------------------------------------------------------
結論：
No DBMS is perfect.
Cache'では、オブジェクトアクセス、ダイレクトアクセス、SQLアクセスを組み合わせて使う。
Subject: newbie questions (新参者の質問)
があります。とても長くなり恐縮ですが参考になりますので要点を書いて、原文をポストします。
Oracle, Sybase, MSSqlの経験者のRayさんという方が、Cache' dbを数日使った後、過去のこのNewsgroupsの内容と、devconのプレゼン資料
(多分 http://
を読み、Cache'に大いに興味を持ち、質問をしたところから始まります。
No.1 Ray Zhangさんの 12 の質問
-------------------------------------------------------
1) 対話型DML(Data Manipulation Language)があるか?
2) 端末モードが初心者にアンフレンドリー
3) Oracleよりなぜ 5-20倍早いかの説明、どんなテストでの比較か？
Cache'の設計思想は?
昼夜いずれの処理でも上の性能差が出ることの説明が、B-treeとSparse array だけでなぜ出来るのかが分からない
Cache'にはそれ固有の弱点があるはずだが、ないのか？
4) Python bindingのもっと説明を
5) CSP(Cache' Server Pages)はどうしてそうスケーラブルなのか？
Apacheで動いている場合、mod_jk2 や mod_perlとほぼ同様に動いているのか？
mod_perlと同様なら、Apacheのスケーラビリティに従属すると思うが?
mod_jk2 と同様なら java app serverのスペーラビリティに従属すると思うが?
6) mod_jk2と同じように動くとして、CSPはどうしてスケーラブルなのか？
app server と db server を同じに考えることは私には理解しにくい。
db serverをstored proceduresのapp serverとみなしたとしても、unix的には別々のものに思えるが?
7) shadow server は hot standby か? ジャーナル（トランザクションログ）で一方向更新のミラーサーバーがある。そうだとしたら、どうそれをスケールアップするのか？
read-only report server については語られず、むしろ real concurrencyとある？
clusteringとdistributed transactionsのサポートは?
two-phase commit は装備されているか？
8) Cache' はACID compliantか?
9) Cache'は concurrency と versioning をどう扱うか?
large transactions をどう扱うのか?
10)mysqlのように data corruption の問題はないか?
does it need to be vacuumed frequently like in postgresql?
11)ハード障害にCache'はどう対応しているのか?
12)Intersystemsの売る立場からすると、Cache'を単なるスタンドアローンDBとしてでなく、db server, app server, OO, csp, dev/design tool (uml?), etc.のセットとして売るほうが有利であるのは理解出来る。しかし、Cache'を OO機能がない他にあるRDBMSのひとつとして考える人にとって、Oracle や Sybase でなくて、Cache'を使う有利性がそこにあるのでしようか？ それとも、Cache'流の（全体セットで考える）考えを受け入れる必要性があるのでしょうか？
上手に質問出来ないので、私が聞きたいことをそちらでうまく理解してもらえるといいですが。
OO機能についてですが、objectstore や objectivity など他のoodbmsと比較してCache'はどうなんでしょうか？ Cache'は、oodbms だから、Oracleに比べ、5-20倍早いのか？ その理由は、oodbms が理論的にも Oracle よりはるかに早いはずだからか、あるいは、Cache'が他でやっていない何か特別なことをしているからなのでしょうか？
この質問を悪く取らないで下さい。誰かに挑もうとしているのではないです。
新しい製品を学ぶ時の私のスタイルなんです。
-------------------------------------------------------
なかなか真摯で突っ込んだ質問です。
この質問に対し、Cache'のOO機能支持者から非支持者まで色々な意見が続きます。
特に12)番目の質問で盛り上がります。
No. 3
M,DSM,Cache'で約15年の経験のあるDennis Coxさんが12の質問に適切に答えています。
-------------------------------------------------------
12) Cache is faster even if you don't use the native object storage but use "old-style" global access. Even with objects, the data is stored in objects, it is just that there is a set of wrapper routines that allow the SQL and object access to the data without knowing the global structure.
-------------------------------------------------------
No. 4
Ramさんが追加で答えてます。
-------------------------------------------------------
> 3) cache must have its own weak spot, no? :)
Many weak spots but don't look for them performance wise.
Intelligent caching and delayed writes have a lot to do with the massive performance gains. But IMHO neither would be possible without the underlying B-tree structure.
> 6)
It's a lot like mod_jk2...
...and Cache'(CSP) scales extremely well but the default licensing model is certainly not amenable to public Web applications (there are special licenses for that though)
デフォルトのライセンスモデルで、CSPをパブリック（インターネット）Webアプりに使うのは適用し難い(certainly not amenable)。他に特別なライセンスもあるが。
これは、CSPではイントラネットばかりでなくインターネットでもブラウザーからCache'サーバーにセッションを張ると（処理がCache'サーバーからブラウザーに戻っても、Cache'サーバのCSPで正常なセッション終了処理がされるか、セッションタイムアウトまで）ライセンスがカウントされていることを意味しているのでしょう。
Cache Server Pages に関するよくある質問
https:/
他に特別なライセンスとは、実アクセスカウント数をベースにライセンス料を払うモデル、あるいは、最近出たRuntimeライセンス（ブラウザー・クライアント数無制限--相当高いようですが?）でしょう。
> 12)
As a "mere" RDBMS with Cache' you get a fast, scalable, stable, low maintenance solution. How's that? :)
Speed does not come from being an OODBMS. The latter benefits from the former.
-------------------------------------------------------
No. 8 Peter Cooperさんが回答追記
No. 10
David Arkellさん（OO機能批判志向）が書きます。
-------------------------------------------------------
All this is very nice in theory. Unfortunately in practise it is somewhat different. You must remember Cache is not by its nature an Object Oriented programming language. This has been grafted ontop of a totally untyped (ie everything is just a string or an array) language.
I advise you not to use the OO features, especially inheritance, any more than you have to. I have spent a couple years maintaining a system that makes extensive use of features like this and it is an absolute nightmare.
すべて理論的にはとてもいいんだか、残念ながら、実際は多少異なる。
Cache'は、本来OOプログラム言語でないことを知っておくべきだ。
完全タイプなし言語の上に接木したみたいなもので、OO機能を(必要以上に、特にインヘリタンスは)使うなとアドバイスしている。
OO機能を過度に使ったシステムを数年メンテナンスして来たが、それは悪夢だった（an absolute nightmare）。
No. 11
これに対してSukesh Hooganさん（OO機能賛成志向）が反論
-------------------------------------------------------
InterSystemsは、pure object-oriented database とは云ってない、post-relational database と呼んでいる。
I am sure you are aware of the more horrible nightmares others have in maintaining relational databases (what with fulltime & highly paid DBAs).
IMO, maintaining a Cache'based system is much easier than the RDBMSs.
もっと悲惨な悪夢はDBAのいるリレーショナルDBでもざらだ。
私見では、Cache'システムはRDBMSよりはるかに簡単だ。
My personal preference is not inheritance of the class definitions ( I do
not even use them), but inheritance & hierarchies of the data.
対Davidさんに、
May be the system you are maintaining was not designed properly, hence the
nightmare.
メンテナンスしていたシステムの設計が適切でなかったから、悪夢だったんじゃないの。
No. 12
Frank Schobさんがその二人の間に入って
-------------------------------------------------------
Sukeshさん、申し訳ないがDavidさんに同意する。
Intersystemsのマーケッティングは、the object data storage and access とそのWebサイトで言ってるよ。
あとライセンスについて触れ
I am not sure which RDBMs you mean. And I can not claim that Cache is a less expensive DBMS, especially if you need more than 200 licenses.
悪夢について
But my experience is "it depends.". As developer I must say its my nightmare too, but I earn my salary with it.
その悪夢のおかげで給料を得てる。
しかし、Sukeshさんの肯定的な経験を知ってうれしい。
最後に、Sukeshさんの大変いいCache'べースのWebサイトをほめています。
It's nice to see that your experience are more positiv. But please consider: We use Cache more as an database (with object storage and access) than as an web application development tool.And finally congratulations to your very good cache-basedc web site
http://
No. 13
DavidさんがSukeshさんに再説明
-------------------------------------------------------
That being said there are some real problems with cache classes. When you have enough classes, persistant and otherwise, cache cannot figure out dependancies propperly. I've lost count of the amount of times we had to compile the entire application because of this. And our application takes over an hour to compile.
Default storageを使うか、自分で定義するかについて
-------------------------------------------------------
You are right about the default storage. I think its pretty good too. I think the major advantage of defining your own is the ability to design your own indices. For example we have an index on username that also contains the password, kinda like this.
^UserGlobal("username-index","user@company.com",[rowID])="password"
With this method when someone tries to log into our application we can check the username/password directly without actually querying the users table. I understand that this is a small thing but its the only simple example i can think of right now.
Of course defining your own storage has its own problems but nothing is
perfect.
-------------------------------------------------------
No. 14
MUMPSで長い経験のある(I have got the grey hairs)Peter Coopesさんのコメント。
-------------------------------------------------------
David
Just a few comments
>I agree with most of what you said. Let me say from the start that I
>don't blame cache entirely for the mess i have to deal with. I think the
>initial programmers found what they thought were really nifty cool
>things they could do and just did them all regardless of whether it was
>appropriate or not.
>initial programmersはほんとにかっこいい素晴らしいと思ったこと、出来ると思ったことをそれが適当、不適かに関わらずやってしまうんです。
Totally agree - you can make some right messes - but with experience(I have got the grey hairs) you can do just the right amout of oo - ISC fell into this trap with their implimentation of streams where there was so much multiple inheritance that I for one could not undertand it
全体的には同意する。しかし、経験(I have got the grey hairs)では、OOも適度には使えます。InterSytemsは、streamsタイプの装備で私には理解できないが multiple inheritance を沢山使ってその中にはまってます。
>That being said there are some real problems with cache classes. When
>you have enough classes, persistant and otherwise, cache cannot figure
>out dependancies propperly. I've lost count of the amount of times we
>had to compile the entire application because of this. And our
>application takes over an hour to compile.
Yes this is a real pain
>And the other thing about classes. They all compile down to mac code. I
>just adds a lot of extra code to make it mimic what objects are supposed
>to do. This affects performance dramatically. The more I program
>directly at the mac level the less time I have for classes.
my rule of thumb is that object access is around 10 times slower than raw access - but have a look at embedded SQL - this can be around 2 times slower than raw access for simple operations but when you get to a comlex insert/update there seems to be little difference between embedded SQL and raw access
-------------------------------------------------------
ここ興味深いですね。
Object access は Raw access(Pure MUMPS グローバルアクセス）に比べ約１０倍遅い。Embedded SQL は単純な処理なら、Raw accessに比べ２倍ぐらい遅いが、複雑なinsert/updateでは Embedded SQL と Raw access はあまり差がない。
-------------------------------------------------------
>You are right about the default storage. I think its pretty good too. I
>think the major advantage of defining your own is the ability to design
>your own indices.
The problem I have with this is that you cannot use bit map indices and these are a real performance boost
>For example we have an index on username that also
>contains the password, kinda like this.
>
>^UserGlobal("username-index","user@company.com",[rowID])="password"
but you can define exactly this structure with objects
objectsでも同じこと出来ますよ。
No. 15
Sukesh HooganさんからFrankさんへ
-------------------------------------------------------
Frank
It has been illuminating discussion so far (that is one of the objectives of such forums).
>And I can not claim that Cache is a less expensive DBMS, especially if you need more than 200 licenses.
Now I would not be able to comment on it. InterSystems is so paranoidly secretive about its pricing model.
InterSystemsは、価格モデルについて、偏執的に秘密主義です。
I only said superb perforamnce, did not say better than custom storage. Having said that, I am loathe to change Cach・s default settings /parameters / design, as I believe with these defaults, Cach・performance is optimal (nobody knows Cache' better than InterSystems and they set the defaults).
私は、デフォルト(storage)を信じます。それを変更する気にはなれない。
Cache'の性能は、デフォルトで最適化されいる（誰もInterSystemsよりCache’を知っている人はいないのだから）
No. 16
最後にSukesh Hooganさんから議論した３人宛てに次の様に収めた。
-------------------------------------------------------
Frank, David & Peter
What I was trying to say that no DBMS is perfect (in fact, there is no such thing as perfect software), each one has it own sets of glitches, bugs and what have you and then there are its positives.
Yes, we all sometimes do try to do things/incorporate code that are/is cool but not appropriate, just to tell oneself "What a clever chap I am"
Hence I use a combination of all three - Object Access / Direct and SQL.
-------------------------------------------------------
結論：
No DBMS is perfect.
Cache'では、オブジェクトアクセス、ダイレクトアクセス、SQLアクセスを組み合わせて使う。
|
|
|
|
コメント(18)
No. 1
intersystems.public.cache:37852
Subject: newbie questions
From: ray <ray@nospamallowed.net>
Date: 11 May 2005 16:28:50 -0500
Hi all,
after playing with Cache db for a few days and reading some old newsgroup posts and devcon presentations, i found the product very interesting and promising, and have a few questions.
my background is with rdbms, e.g., oracle, sybase, mssql, etc, so please execuse my "old-school" thinking :)
1) is there a tool like sqlplus/isql/mysql for creating/inspecting tables and executing DMLs interactively.
i came across a reference to "Do $System.SQL.Oracle()", but that seems to work only in batch mode, and got a bit stuck when asked for device. full unix path to the DDL file didn't do the trick...
2) the terminal (csession) is not very newbie-friendly. it will take me a while to get used to commands like "zn". in fact, i start to call it the "z-shell" :) no online help?
3) is there any explaination on why cache runs 5-20x faster than oracle? what kind of perf test were done? for oracle vs mssql, at least one can differentiate on the basis of scale-up vs scale-out. what's cache's design philosophy? i don't see how B-tree and sparse array alone can explain this day-and-night perf difference. cache must have its own weak spot, no? :)
4) came across a brief mentioning to Python binding support in the docs. are there any more detailed docs on that? e.g., where to get Python driver?
5) on CSP, how well does it scale? when using it with apache, does it work more or less like mod_jk2 and mod_perl?
if it's like mod_perl, then i suppose the scalability depends on apache's scalability?
if it's like mod_jk2, then it will depend on java app server?
6) so, suppose it works like mod_jk2, how does CSP scale? there is one devcon presentation, which i read very quickly, that talks about single-tier and multi-tier scaling. i guess i am having trouble understanding how app server and db server can be the same thing. granted, any db server can be viewed as an app server for processing stored procedures, yet i am still used to the unix philosophy of do one thing and do one it well.
7) is shadow server like a hot standby? hence only one-way mirror based on journal (transaction logs)? if that's the case, how does it scale? not talking about read-only report server, but rather real concurrency. any support for clustering and distributed transactions? does it implement two-phase commit?
8) is cache ACID compliant?
9) how does cache handle concurrency and versioning? does it do something like oracle's rollback segment?
how does it handle large transactions? does it require the applications to commit frequently? or it's a non-issue?
i.e., transactions can be as large as required by business needs. does cache have issue with lock resources like mssql does?
10) does it have data corruption issues like mysql does? :) does it need to be vacuumed frequently like in postgresql?
11) how well does cache handle hardware failures? can i randomly kill processes and/or pull out disks and expect commited transactions not to be lost, as long as i have recent backup and archive logs (sorry about using oracle terminology)?
if yes, how is it implemented? roll-forward then roll-back upon restart?
12) i can understand from intersystem's point of view, it's beneficial to sell cache not just as a standalone db product, but as a whole suite of solutions: db server, app server, OO, csp, dev/design tool (uml?), etc.
however, if one were to treat cache as just any rdbms out there, without considering its OO-capability, will he still reap the benefit of using cache as opposed to oracle or sybase? or it's necessary to buy into this whole cache way of thinking? i know i am not phrasing this question very well, but hopefully you will understand what i am trying to ask. and if taking into account of OO-capability, how does cache compare to other oodbms, say objectstore (progress-owned?) and objectivity? is cache 5-20x faster than oracle because its an oodbms, which will imply other oodbms should in theory also be much faster than oracle, or is it because cache is doing something so special that no one else is doing?
please don't take these questions the wrong way. i am not trying to challenge anyone. just my style of learning new products :) and look forward to your replies
thanks very much in advance,
- ray zhang
intersystems.public.cache:37852
Subject: newbie questions
From: ray <ray@nospamallowed.net>
Date: 11 May 2005 16:28:50 -0500
Hi all,
after playing with Cache db for a few days and reading some old newsgroup posts and devcon presentations, i found the product very interesting and promising, and have a few questions.
my background is with rdbms, e.g., oracle, sybase, mssql, etc, so please execuse my "old-school" thinking :)
1) is there a tool like sqlplus/isql/mysql for creating/inspecting tables and executing DMLs interactively.
i came across a reference to "Do $System.SQL.Oracle()", but that seems to work only in batch mode, and got a bit stuck when asked for device. full unix path to the DDL file didn't do the trick...
2) the terminal (csession) is not very newbie-friendly. it will take me a while to get used to commands like "zn". in fact, i start to call it the "z-shell" :) no online help?
3) is there any explaination on why cache runs 5-20x faster than oracle? what kind of perf test were done? for oracle vs mssql, at least one can differentiate on the basis of scale-up vs scale-out. what's cache's design philosophy? i don't see how B-tree and sparse array alone can explain this day-and-night perf difference. cache must have its own weak spot, no? :)
4) came across a brief mentioning to Python binding support in the docs. are there any more detailed docs on that? e.g., where to get Python driver?
5) on CSP, how well does it scale? when using it with apache, does it work more or less like mod_jk2 and mod_perl?
if it's like mod_perl, then i suppose the scalability depends on apache's scalability?
if it's like mod_jk2, then it will depend on java app server?
6) so, suppose it works like mod_jk2, how does CSP scale? there is one devcon presentation, which i read very quickly, that talks about single-tier and multi-tier scaling. i guess i am having trouble understanding how app server and db server can be the same thing. granted, any db server can be viewed as an app server for processing stored procedures, yet i am still used to the unix philosophy of do one thing and do one it well.
7) is shadow server like a hot standby? hence only one-way mirror based on journal (transaction logs)? if that's the case, how does it scale? not talking about read-only report server, but rather real concurrency. any support for clustering and distributed transactions? does it implement two-phase commit?
8) is cache ACID compliant?
9) how does cache handle concurrency and versioning? does it do something like oracle's rollback segment?
how does it handle large transactions? does it require the applications to commit frequently? or it's a non-issue?
i.e., transactions can be as large as required by business needs. does cache have issue with lock resources like mssql does?
10) does it have data corruption issues like mysql does? :) does it need to be vacuumed frequently like in postgresql?
11) how well does cache handle hardware failures? can i randomly kill processes and/or pull out disks and expect commited transactions not to be lost, as long as i have recent backup and archive logs (sorry about using oracle terminology)?
if yes, how is it implemented? roll-forward then roll-back upon restart?
12) i can understand from intersystem's point of view, it's beneficial to sell cache not just as a standalone db product, but as a whole suite of solutions: db server, app server, OO, csp, dev/design tool (uml?), etc.
however, if one were to treat cache as just any rdbms out there, without considering its OO-capability, will he still reap the benefit of using cache as opposed to oracle or sybase? or it's necessary to buy into this whole cache way of thinking? i know i am not phrasing this question very well, but hopefully you will understand what i am trying to ask. and if taking into account of OO-capability, how does cache compare to other oodbms, say objectstore (progress-owned?) and objectivity? is cache 5-20x faster than oracle because its an oodbms, which will imply other oodbms should in theory also be much faster than oracle, or is it because cache is doing something so special that no one else is doing?
please don't take these questions the wrong way. i am not trying to challenge anyone. just my style of learning new products :) and look forward to your replies
thanks very much in advance,
- ray zhang
No. 2
intersystems.public.cache:37853
From: "Sukesh Hoogan" <sukeshhoogan@NOSPAMvsnl.com>
Subject: Re: newbie questions
Date: Thu, 12 May 2005 03:27:36 +0530
Ray
Welcome aboard
Phew! Your post seems like an examniation paper.
Anyway, members here would respond to your specific queries.
Have fun with Cach・
Regards
Sukesh Hoogan
e-Linear Enterprise Solutions
Bombay (India)
http://personal.vsnl.com/sukesh_hoogan
intersystems.public.cache:37853
From: "Sukesh Hoogan" <sukeshhoogan@NOSPAMvsnl.com>
Subject: Re: newbie questions
Date: Thu, 12 May 2005 03:27:36 +0530
Ray
Welcome aboard
Phew! Your post seems like an examniation paper.
Anyway, members here would respond to your specific queries.
Have fun with Cach・
Regards
Sukesh Hoogan
e-Linear Enterprise Solutions
Bombay (India)
http://personal.vsnl.com/sukesh_hoogan
No. 3
intersystems.public.cache:37855
From: "Dennis Cox" <dennisthis@ebdthistoocorp.com>
Subject: Re: newbie questions
Date: Wed, 11 May 2005 19:17:48 -0500
Welcome to Cache. I cannot answer all of your questions, but here is my take on a few of them. I've used M, DSM, and Cache for about 15 years. The last 7 or so have been in Cache. I work on a high volume 24x7 application running cache on a wintel environment. It is very reliable and fast.
1) Not sure what a DML is, but there is SQL Manager that you can access from the Cache cube for viewing tables and running queries. Or you can just use something like WinSQL or Excel.
2) Terminal is AKA programmer mode/prompt. You can do almost (or all) everything you need to do without it by using the GUI utilities from the cube. Us old-timers still like using terminal though.
3) Don't know how they do it, but it smokes.
10) There is such a thing as database corruption in Cache, but it is
very, very rare. Not sure what vacuuming means to postgresql.
11) If journalling is enabled and backups are reliable, then HW failures should not hurt the database. You may have to restore the backup and replay the journal files since the last backup to get it up to the point of the failure but if something was committed to the database in a transaction, then it should be there when you recover the HW.
12) Cache is faster even if you don't use the native object storage but use "old-style" global access. Even with objects, the data is stored in objects, it is just that there is a set of wrapper routines that allow the SQL and object access to the data without knowing the global structure.
Hope this helps,
Dennis
intersystems.public.cache:37855
From: "Dennis Cox" <dennisthis@ebdthistoocorp.com>
Subject: Re: newbie questions
Date: Wed, 11 May 2005 19:17:48 -0500
Welcome to Cache. I cannot answer all of your questions, but here is my take on a few of them. I've used M, DSM, and Cache for about 15 years. The last 7 or so have been in Cache. I work on a high volume 24x7 application running cache on a wintel environment. It is very reliable and fast.
1) Not sure what a DML is, but there is SQL Manager that you can access from the Cache cube for viewing tables and running queries. Or you can just use something like WinSQL or Excel.
2) Terminal is AKA programmer mode/prompt. You can do almost (or all) everything you need to do without it by using the GUI utilities from the cube. Us old-timers still like using terminal though.
3) Don't know how they do it, but it smokes.
10) There is such a thing as database corruption in Cache, but it is
very, very rare. Not sure what vacuuming means to postgresql.
11) If journalling is enabled and backups are reliable, then HW failures should not hurt the database. You may have to restore the backup and replay the journal files since the last backup to get it up to the point of the failure but if something was committed to the database in a transaction, then it should be there when you recover the HW.
12) Cache is faster even if you don't use the native object storage but use "old-style" global access. Even with objects, the data is stored in objects, it is just that there is a set of wrapper routines that allow the SQL and object access to the data without knowing the global structure.
Hope this helps,
Dennis
No. 4
intersystems.public.cache:37869
Date: Thu, 12 May 2005 10:31:13 -0400
From: =?ISO-8859-1?Q?Ram=F3n_Jim=E9nez?= <rjimenez@zcachelib.org>
Subject: Re: newbie questions
Ray,
Sorry if I sound too terse - this is a long list of questions! :) Here we go:
> 1) is there a tool like sqlplus/isql/mysql for creating/inspecting tables
> and executing DMLs interactively.
> i came across a reference to "Do $System.SQL.Oracle()", but that seems to
> work only in batch mode, and got a bit stuck when asked for device. full
> unix path to the DDL file didn't do the trick...
DO $system.SQL.Shell()
> 3) is there any explaination on why cache runs 5-20x faster than oracle?
> what kind of perf test were done? for oracle vs mssql, at least one can
> differentiate on the basis of scale-up vs scale-out. what's cache's
> design philosophy? i don't see how B-tree and sparse array alone can
> explain this day-and-night perf difference. cache must have its own weak
> spot, no? :)
Many weak spots but don't look for them performance wise.
Intelligent caching and delayed writes have a lot to do with the massive performance gains. But IMHO neither would be possible without the underlying B-tree structure.
> 4) came across a brief mentioning to Python binding support in the docs.
> are there any more detailed docs on that? e.g., where to get Python
> driver?
This is to be relased in the next version of Cach・ Don't ask when that is, no one knows.
> 5) on CSP, how well does it scale? when using it with apache, does it
> work more or less like mod_jk2 and mod_perl?
> if it's like mod_perl, then i suppose the scalability depends on apache's
> scalability?
> if it's like mod_jk2, then it will depend on java app server?
It's a lot like mod_jk2...
> 6) so, suppose it works like mod_jk2, how does CSP scale? there is one
> devcon presentation, which i read very quickly, that talks about single-
> tier and multi-tier scaling. i guess i am having trouble understanding
> how app server and db server can be the same thing. granted, any db
> server can be viewed as an app server for processing stored
> procedures, yet i am still used to the unix philosophy of do one thing
> and do one it well.
...and Cach・(CSP) scales extremely well but the default licensing model is certainly not amenable to public Web applications (there are special licenses for that though)
> 7) is shadow server like a hot standby? hence only one-way mirror based
> on journal (transaction logs)? if that's the case, how does it scale?
> not talking about read-only report server, but rather real concurrency.
> any support for clustering and distributed transactions? does it
> implement two-phase commit?
Shadowing is as you describe, I however cannot comment (yet) on scalability.
> 8) is cache ACID compliant?
It depends. Objects are transactional. You must have journaling enabled.
> 10) does it have data corruption issues like mysql does? :) does it need
> to be vacuumed frequently like in postgresql?
No and no (but I'm not aware of those data corruption issues in MySQL you mention).
Do keep in mind that data corruption typically relies on a lot of external factors (hard drive failure, power outage...) I don't think any modern DBMS would corrupt volumes by itself. Bugs do exist, naturally.
> 12) i can understand from intersystem's point of view, it's beneficial to
> sell cache not just as a standalone db product, but as a whole suite of
> solutions: db server, app server, OO, csp, dev/design tool (uml?), etc.
> however, if one were to treat cache as just any rdbms out there, without
> considering its OO-capability, will he still reap the benefit of using
> cache as opposed to oracle or sybase? or it's necessary to buy into this
> whole cache way of thinking?
As a "mere" RDBMS with Cach・you get a fast, scalable, stable, low maintenance solution. How's that? :)
> taking into account of OO-capability, how does cache compare to other
> oodbms, say objectstore (progress-owned?) and objectivity? is cache 5-
> 20x faster than oracle because its an oodbms, which will imply other
> oodbms should in theory also be much faster than oracle, or is it because
> cache is doing something so special that no one else is doing?
Speed does not come from being an OODBMS. The latter benefits from the former.
I cannot comment on how Cach・itself fares against other OODBMSs.
> please don't take these questions the wrong way. i am not trying to > challenge anyone. just my style of learning new products :) and look > forward to your replies
Your questions are very thorough and it seems like you know how to properly evaluate a new piece of software :) Do expect, however, that a lot of people will weigh in and have lots of opinions on your questions. Hopefully you'll come out with the information you're looking for.
Regards,
Ram〓
intersystems.public.cache:37869
Date: Thu, 12 May 2005 10:31:13 -0400
From: =?ISO-8859-1?Q?Ram=F3n_Jim=E9nez?= <rjimenez@zcachelib.org>
Subject: Re: newbie questions
Ray,
Sorry if I sound too terse - this is a long list of questions! :) Here we go:
> 1) is there a tool like sqlplus/isql/mysql for creating/inspecting tables
> and executing DMLs interactively.
> i came across a reference to "Do $System.SQL.Oracle()", but that seems to
> work only in batch mode, and got a bit stuck when asked for device. full
> unix path to the DDL file didn't do the trick...
DO $system.SQL.Shell()
> 3) is there any explaination on why cache runs 5-20x faster than oracle?
> what kind of perf test were done? for oracle vs mssql, at least one can
> differentiate on the basis of scale-up vs scale-out. what's cache's
> design philosophy? i don't see how B-tree and sparse array alone can
> explain this day-and-night perf difference. cache must have its own weak
> spot, no? :)
Many weak spots but don't look for them performance wise.
Intelligent caching and delayed writes have a lot to do with the massive performance gains. But IMHO neither would be possible without the underlying B-tree structure.
> 4) came across a brief mentioning to Python binding support in the docs.
> are there any more detailed docs on that? e.g., where to get Python
> driver?
This is to be relased in the next version of Cach・ Don't ask when that is, no one knows.
> 5) on CSP, how well does it scale? when using it with apache, does it
> work more or less like mod_jk2 and mod_perl?
> if it's like mod_perl, then i suppose the scalability depends on apache's
> scalability?
> if it's like mod_jk2, then it will depend on java app server?
It's a lot like mod_jk2...
> 6) so, suppose it works like mod_jk2, how does CSP scale? there is one
> devcon presentation, which i read very quickly, that talks about single-
> tier and multi-tier scaling. i guess i am having trouble understanding
> how app server and db server can be the same thing. granted, any db
> server can be viewed as an app server for processing stored
> procedures, yet i am still used to the unix philosophy of do one thing
> and do one it well.
...and Cach・(CSP) scales extremely well but the default licensing model is certainly not amenable to public Web applications (there are special licenses for that though)
> 7) is shadow server like a hot standby? hence only one-way mirror based
> on journal (transaction logs)? if that's the case, how does it scale?
> not talking about read-only report server, but rather real concurrency.
> any support for clustering and distributed transactions? does it
> implement two-phase commit?
Shadowing is as you describe, I however cannot comment (yet) on scalability.
> 8) is cache ACID compliant?
It depends. Objects are transactional. You must have journaling enabled.
> 10) does it have data corruption issues like mysql does? :) does it need
> to be vacuumed frequently like in postgresql?
No and no (but I'm not aware of those data corruption issues in MySQL you mention).
Do keep in mind that data corruption typically relies on a lot of external factors (hard drive failure, power outage...) I don't think any modern DBMS would corrupt volumes by itself. Bugs do exist, naturally.
> 12) i can understand from intersystem's point of view, it's beneficial to
> sell cache not just as a standalone db product, but as a whole suite of
> solutions: db server, app server, OO, csp, dev/design tool (uml?), etc.
> however, if one were to treat cache as just any rdbms out there, without
> considering its OO-capability, will he still reap the benefit of using
> cache as opposed to oracle or sybase? or it's necessary to buy into this
> whole cache way of thinking?
As a "mere" RDBMS with Cach・you get a fast, scalable, stable, low maintenance solution. How's that? :)
> taking into account of OO-capability, how does cache compare to other
> oodbms, say objectstore (progress-owned?) and objectivity? is cache 5-
> 20x faster than oracle because its an oodbms, which will imply other
> oodbms should in theory also be much faster than oracle, or is it because
> cache is doing something so special that no one else is doing?
Speed does not come from being an OODBMS. The latter benefits from the former.
I cannot comment on how Cach・itself fares against other OODBMSs.
> please don't take these questions the wrong way. i am not trying to > challenge anyone. just my style of learning new products :) and look > forward to your replies
Your questions are very thorough and it seems like you know how to properly evaluate a new piece of software :) Do expect, however, that a lot of people will weigh in and have lots of opinions on your questions. Hopefully you'll come out with the information you're looking for.
Regards,
Ram〓
No. 5
intersystems.public.cache:37885
Subject: Re: newbie questions
From: ray <ray@nospamallowed.net>
Date: 12 May 2005 18:23:13 -0500
thank you all for the quick replies and look forward to more :)
here is a question on SQL.Shell()
> DO $system.SQL.Shell()
somehow, from the shell, i can't see the tables. would be nice if there were a "show tables" command. i feel very handicapped when not being able to see tables at command line :)
but i did verify that "employee" table exists by ODBC in with MS Access, using the system DSN that's automatically setup during Cache installation: CACHEWEB Samples. heck, even reverse-engineer with PowerDesigner worked -- tables showed up. could this be a permission issue? setuser to _system didn't make any difference.
USER>zn "samples"
SAMPLES>DO $system.SQL.Shell()
>>select count(1) from employee
(1)>>go
ERROR: 30 Table or View not found
>>setuser _system sys
User _SYSTEM successfully logged on....
>>setuser
= _SYSTEM
>>select count(1) from employee
(1)>>go
ERROR: 30 Table or View not found
- ray
intersystems.public.cache:37885
Subject: Re: newbie questions
From: ray <ray@nospamallowed.net>
Date: 12 May 2005 18:23:13 -0500
thank you all for the quick replies and look forward to more :)
here is a question on SQL.Shell()
> DO $system.SQL.Shell()
somehow, from the shell, i can't see the tables. would be nice if there were a "show tables" command. i feel very handicapped when not being able to see tables at command line :)
but i did verify that "employee" table exists by ODBC in with MS Access, using the system DSN that's automatically setup during Cache installation: CACHEWEB Samples. heck, even reverse-engineer with PowerDesigner worked -- tables showed up. could this be a permission issue? setuser to _system didn't make any difference.
USER>zn "samples"
SAMPLES>DO $system.SQL.Shell()
>>select count(1) from employee
(1)>>go
ERROR: 30 Table or View not found
>>setuser _system sys
User _SYSTEM successfully logged on....
>>setuser
= _SYSTEM
>>select count(1) from employee
(1)>>go
ERROR: 30 Table or View not found
- ray
No. 6
intersystems.public.cache:37891
Date: Fri, 13 May 2005 09:11:56 -0400
From: =?ISO-8859-1?Q?Ram=F3n_Jim=E9nez?= <rjimenez@zcachelib.org>
Subject: Re: newbie questions
ray
You must use fully qualified table names:
> USER>zn "samples"
>
> SAMPLES>DO $system.SQL.Shell()
>
>
>>>select count(1) from employee
select count(1) from sample.employee
HTH,
Ram〓
intersystems.public.cache:37891
Date: Fri, 13 May 2005 09:11:56 -0400
From: =?ISO-8859-1?Q?Ram=F3n_Jim=E9nez?= <rjimenez@zcachelib.org>
Subject: Re: newbie questions
ray
You must use fully qualified table names:
> USER>zn "samples"
>
> SAMPLES>DO $system.SQL.Shell()
>
>
>>>select count(1) from employee
select count(1) from sample.employee
HTH,
Ram〓
No. 7
intersystems.public.cache:37901
From: "Andre Cerri" <cerri@intersys_deletethisbit_tems.com>
Subject: Re: newbie questions
Date: Fri, 13 May 2005 14:26:11 -0400
To qualify that, you need to use quailified table names if accessing a table in the non-default schema, which in itself defaults to sqluser. This can be modified in Config Manager.
HTH
andre
intersystems.public.cache:37901
From: "Andre Cerri" <cerri@intersys_deletethisbit_tems.com>
Subject: Re: newbie questions
Date: Fri, 13 May 2005 14:26:11 -0400
To qualify that, you need to use quailified table names if accessing a table in the non-default schema, which in itself defaults to sqluser. This can be modified in Config Manager.
HTH
andre
No. 8
intersystems.public.cache:37919
From: Peter Cooper <pfc@xisltd.demon.co.uk>
Subject: Re: newbie questions
Date: Mon, 16 May 2005 01:14:32 +0100
Ray
Welcome aboard
some few comments to add to the other excellent posts
>2) the terminal (csession) is not very newbie-friendly.......
It's the history of Cache - at the terminal prompt you an do anything
kill ^SomeTableD
and it's gone !!!!
the key here is to realise that Cache is the programming language and the Db - forget the barrier between you and the data in RDBMS systems you have complete control
>3) is there any explaination on why cache runs 5-20x faster than oracle....
be careful here if you use "simple" selects then Cache will be slower - where it is faster is in "real life" multi user transaction processing
>5) on CSP, how well does it scale? ....
The concept here is that you have a single data server - all it does it keep the data. You then have an array of app servers these are running IIS/Apache and controlling the client comms but they get their data from the single app server
So you have the app servers dealing with all the TCP IO, translating from stored to html etc etc and the data server just doing the data.
this is due to the history of Cach suporting large, distributed systems - they have a lot of experience in doing this
>12) i can understand from intersystem's point of view, it's beneficial to
>sell cache not just as a standalone db product, but as a whole suite of
>solutions: db server, app server, OO, csp, dev/design tool (uml?), etc.
This is not quite true - Cache does what it does, the db/app server are a matter of configuration - ISC are a database company period (well lets ignore Ensemble for the moment)
It lacks in the design tools (eg UML is only available from 3rd party and it's only one way), source control (3rd party), a buggy IDE, CSP excellent - but the object bind technology only really good for demo's
My personal take on this is, that compared with a RDBMS it holds it's own in performance (no more than that***) but to get best you need to design things from the ground up in oo - and that's a completely different story - but not so strange,eg I am involved with a client's on-line system - the supplier is using mySql, nothing against that, but the supplier is lacking intellectual power (oo or RDBMS), having a few clients (successful) and now growing it's all breaking because they have a faulty data model.
All I can say here is that it's easier to build a robust data model on an oo environment than RDBMS
Just do it - but you have to climb the learning curve from RDBMS to oo
Peter
*** but it's far more robust
intersystems.public.cache:37919
From: Peter Cooper <pfc@xisltd.demon.co.uk>
Subject: Re: newbie questions
Date: Mon, 16 May 2005 01:14:32 +0100
Ray
Welcome aboard
some few comments to add to the other excellent posts
>2) the terminal (csession) is not very newbie-friendly.......
It's the history of Cache - at the terminal prompt you an do anything
kill ^SomeTableD
and it's gone !!!!
the key here is to realise that Cache is the programming language and the Db - forget the barrier between you and the data in RDBMS systems you have complete control
>3) is there any explaination on why cache runs 5-20x faster than oracle....
be careful here if you use "simple" selects then Cache will be slower - where it is faster is in "real life" multi user transaction processing
>5) on CSP, how well does it scale? ....
The concept here is that you have a single data server - all it does it keep the data. You then have an array of app servers these are running IIS/Apache and controlling the client comms but they get their data from the single app server
So you have the app servers dealing with all the TCP IO, translating from stored to html etc etc and the data server just doing the data.
this is due to the history of Cach suporting large, distributed systems - they have a lot of experience in doing this
>12) i can understand from intersystem's point of view, it's beneficial to
>sell cache not just as a standalone db product, but as a whole suite of
>solutions: db server, app server, OO, csp, dev/design tool (uml?), etc.
This is not quite true - Cache does what it does, the db/app server are a matter of configuration - ISC are a database company period (well lets ignore Ensemble for the moment)
It lacks in the design tools (eg UML is only available from 3rd party and it's only one way), source control (3rd party), a buggy IDE, CSP excellent - but the object bind technology only really good for demo's
My personal take on this is, that compared with a RDBMS it holds it's own in performance (no more than that***) but to get best you need to design things from the ground up in oo - and that's a completely different story - but not so strange,eg I am involved with a client's on-line system - the supplier is using mySql, nothing against that, but the supplier is lacking intellectual power (oo or RDBMS), having a few clients (successful) and now growing it's all breaking because they have a faulty data model.
All I can say here is that it's easier to build a robust data model on an oo environment than RDBMS
Just do it - but you have to climb the learning curve from RDBMS to oo
Peter
*** but it's far more robust
No. 9
intersystems.public.cache:37920
Subject: Re: newbie questions
From: Ged <ged@nobrot.co.uk>
Date: 16 May 2005 04:13:30 -0500
i second that
you can just convert your access tables to cache and run it as a backend dataserver and it will work a lot better than access mutiuser (been there, done that)
but if you redesign the tables to take advantage of cache it will work a lot better.
things like parent/child relationships (you SEE the relationship in the Table),sub classing and calculated fields come to mind as well as strings
> 255 (and an automatic ID field for those of a forgetful nature)
if you are going for web delivery then that is build in too.
write the web pages in html or use csp tags or just write it in COS the choice is yours and you have complete control of what you are doing.
using the (almost) same bit of code in every page ? write a "macro" (csp rule) supply it with arguements and let it get on with it :-)
the supplied class and webpage wizards don't do what You want ? write your own ! (they are only html pages after all)
the learning curve, however, can be steep especially if you are not as young as you were.
but when you Do reach Critical Mass the rewards Are worthwhile :-)
HTH
Ged
(oh, did i mention self documenting class definitions ?)
intersystems.public.cache:37920
Subject: Re: newbie questions
From: Ged <ged@nobrot.co.uk>
Date: 16 May 2005 04:13:30 -0500
i second that
you can just convert your access tables to cache and run it as a backend dataserver and it will work a lot better than access mutiuser (been there, done that)
but if you redesign the tables to take advantage of cache it will work a lot better.
things like parent/child relationships (you SEE the relationship in the Table),sub classing and calculated fields come to mind as well as strings
> 255 (and an automatic ID field for those of a forgetful nature)
if you are going for web delivery then that is build in too.
write the web pages in html or use csp tags or just write it in COS the choice is yours and you have complete control of what you are doing.
using the (almost) same bit of code in every page ? write a "macro" (csp rule) supply it with arguements and let it get on with it :-)
the supplied class and webpage wizards don't do what You want ? write your own ! (they are only html pages after all)
the learning curve, however, can be steep especially if you are not as young as you were.
but when you Do reach Critical Mass the rewards Are worthwhile :-)
HTH
Ged
(oh, did i mention self documenting class definitions ?)
No. 10
intersystems.public.cache:37925
Date: Mon, 16 May 2005 18:53:20 +0100
From: David Arkell <david.arkell@mtivity.com>
Subject: Re: newbie questions
All this is very nice in theory. Unfortunately in practise it is somewhat different. You must remember Cache is not by its nature an Object Oriented programming language. This has been grafted ontop of a totally untyped (ie everything is just a string or an array) language.
I advise you not to use the OO features, especially inheritance, any more than you have to. I have spent a couple years maintaining a system that makes extensive use of features like this and it is an absolute nightmare.
I agree totally about needing a good design. It makes the world of difference.
As for performance, you can get an amazing amounts of speed out of cache but to do this you generally have to define your own storage and use the classes as just wrappers. You definately have to know what you're doing if you code this way because it is less forgiving of mistakes. But if you need the best performance this is the only way to go.
David
intersystems.public.cache:37925
Date: Mon, 16 May 2005 18:53:20 +0100
From: David Arkell <david.arkell@mtivity.com>
Subject: Re: newbie questions
All this is very nice in theory. Unfortunately in practise it is somewhat different. You must remember Cache is not by its nature an Object Oriented programming language. This has been grafted ontop of a totally untyped (ie everything is just a string or an array) language.
I advise you not to use the OO features, especially inheritance, any more than you have to. I have spent a couple years maintaining a system that makes extensive use of features like this and it is an absolute nightmare.
I agree totally about needing a good design. It makes the world of difference.
As for performance, you can get an amazing amounts of speed out of cache but to do this you generally have to define your own storage and use the classes as just wrappers. You definately have to know what you're doing if you code this way because it is less forgiving of mistakes. But if you need the best performance this is the only way to go.
David
No. 11
intersystems.public.cache:37931
From: "Sukesh Hoogan" <sukeshhoogan@NOSPAMvsnl.com>
Subject: Re: newbie questions
Date: Tue, 17 May 2005 06:21:33 +0530
David
My sympathies for the absolute nightmare you mentioned.
See in-line
Regards
Sukesh Hoogan
e-Linear Enterprise Solutions
Bombay (India)
http://personal.vsnl.com/sukesh_hoogan
"David Arkell" <david.arkell@mtivity.com> wrote in message
news:4288e04c.0@info2.kinich.com...
> All this is very nice in theory. Unfortunately in practise it is
> somewhat different. You must remember Cache is not by its nature an
> Object Oriented programming language. This has been grafted ontop of a
> totally untyped (ie everything is just a string or an array) language.
I think, InterSystems have never claimed Cach・to be a pure object-oriented database. They have called it the post-relational database.
Yes, they say Cach・ObjectScript (as the name implies) is an object programming language designed for rapidly developing complex business applications
> I advise you not to use the OO features, especially inheritance, any
> more than you have to. I have spent a couple years maintaining a system
> that makes extensive use of features like this and it is an absolute
> nightmare.
I am sure you are aware of the more horrible nightmares others have in maintaining relational databases (what with fulltime & highly paid DBAs). IMO, maintaining a Cach・based system is much easier than the RDBMSs.
My personal preference is not inheritance of the class definitions ( I do not even use them), but inheritance & hierarchies of the data.
> I agree totally about needing a good design. It makes the world of
> difference.
May be the system you are maintaining was not designed properly, hence the nightmare.
> As for performance, you can get an amazing amounts of speed out of cache
> but to do this you generally have to define your own storage and use the
> classes as just wrappers. You definately have to know what you're doing
Even default storage, and of course one has to know what one is doing, gives you superb performance.
> if you code this way because it is less forgiving of mistakes. But if
> you need the best performance this is the only way to go.
> David
>
>
> Peter Cooper wrote:
> > Ray
> >
> > Welcome aboard
> >
> > some few comments to add to the other excellent posts
> >
> >
> >
> >>2) the terminal (csession) is not very newbie-friendly.......
> >
> >
> > It's the history of Cache - at the terminal prompt you an do anything
> > kill ^SomeTableD
> > and it's gone !!!!
> > the key here is to realise that Cache is the programming language and
> > the Db - forget the barrier between you and the data in RDBMS systems
> > you have complete control
> >
> >
> >>3) is there any explaination on why cache runs 5-20x faster than
oracle....
> >
> > be careful here if you use "simple" selects then Cache will be slower
> > - where it is faster is in "real life" multi user transaction
> > processing
> >
> >
> >>5) on CSP, how well does it scale? ....
> >
> > The concept here is that you have a single data server - all it does
> > it keep the data. You then have an array of app servers these are
> > running IIS/Apache and controlling the client comms but they get their
> > data from the single app server
> > So you have the app servers dealing with all the TCP IO, translating
> > from stored to html etc etc and the data server just doing the data.
> >
> > this is due to the history of Cach suporting large, distributed
> > systems - they have a lot of experience in doing this
> >
> >
> >
> >>12) i can understand from intersystem's point of view, it's beneficial
to
> >>sell cache not just as a standalone db product, but as a whole suite of
> >>solutions: db server, app server, OO, csp, dev/design tool (uml?), etc.
> >
> > This is not quite true - Cache does what it does, the db/app server
> > are a matter of configuration - ISC are a database company period
> > (well lets ignore Ensemble for the moment)
> > It lacks in the design tools (eg UML is only available from 3rd party
> > and it's only one way), source control (3rd party), a buggy IDE, CSP
> > excellent - but the object bind technology only really good for demo's
> >
> > My personal take on this is, that compared with a RDBMS it holds it's
> > own in performance (no more than that***) but to get best you need to
> > design things from the ground up in oo - and that's a completely
> > different story - but not so strange,eg I am involved with a client's
> > on-line system - the supplier is using mySql, nothing against that,
> > but the supplier is lacking intellectual power (oo or RDBMS), having a
> > few clients (successful) and now growing it's all breaking because
> > they have a faulty data model.
> > All I can say here is that it's easier to build a robust data model on
> > an oo environment than RDBMS
> >
> >
> > Just do it - but you have to climb the learning curve from RDBMS to oo
> >
> > Peter
> >
> > *** but it's far more robust
> >
> >
> >
intersystems.public.cache:37931
From: "Sukesh Hoogan" <sukeshhoogan@NOSPAMvsnl.com>
Subject: Re: newbie questions
Date: Tue, 17 May 2005 06:21:33 +0530
David
My sympathies for the absolute nightmare you mentioned.
See in-line
Regards
Sukesh Hoogan
e-Linear Enterprise Solutions
Bombay (India)
http://personal.vsnl.com/sukesh_hoogan
"David Arkell" <david.arkell@mtivity.com> wrote in message
news:4288e04c.0@info2.kinich.com...
> All this is very nice in theory. Unfortunately in practise it is
> somewhat different. You must remember Cache is not by its nature an
> Object Oriented programming language. This has been grafted ontop of a
> totally untyped (ie everything is just a string or an array) language.
I think, InterSystems have never claimed Cach・to be a pure object-oriented database. They have called it the post-relational database.
Yes, they say Cach・ObjectScript (as the name implies) is an object programming language designed for rapidly developing complex business applications
> I advise you not to use the OO features, especially inheritance, any
> more than you have to. I have spent a couple years maintaining a system
> that makes extensive use of features like this and it is an absolute
> nightmare.
I am sure you are aware of the more horrible nightmares others have in maintaining relational databases (what with fulltime & highly paid DBAs). IMO, maintaining a Cach・based system is much easier than the RDBMSs.
My personal preference is not inheritance of the class definitions ( I do not even use them), but inheritance & hierarchies of the data.
> I agree totally about needing a good design. It makes the world of
> difference.
May be the system you are maintaining was not designed properly, hence the nightmare.
> As for performance, you can get an amazing amounts of speed out of cache
> but to do this you generally have to define your own storage and use the
> classes as just wrappers. You definately have to know what you're doing
Even default storage, and of course one has to know what one is doing, gives you superb performance.
> if you code this way because it is less forgiving of mistakes. But if
> you need the best performance this is the only way to go.
> David
>
>
> Peter Cooper wrote:
> > Ray
> >
> > Welcome aboard
> >
> > some few comments to add to the other excellent posts
> >
> >
> >
> >>2) the terminal (csession) is not very newbie-friendly.......
> >
> >
> > It's the history of Cache - at the terminal prompt you an do anything
> > kill ^SomeTableD
> > and it's gone !!!!
> > the key here is to realise that Cache is the programming language and
> > the Db - forget the barrier between you and the data in RDBMS systems
> > you have complete control
> >
> >
> >>3) is there any explaination on why cache runs 5-20x faster than
oracle....
> >
> > be careful here if you use "simple" selects then Cache will be slower
> > - where it is faster is in "real life" multi user transaction
> > processing
> >
> >
> >>5) on CSP, how well does it scale? ....
> >
> > The concept here is that you have a single data server - all it does
> > it keep the data. You then have an array of app servers these are
> > running IIS/Apache and controlling the client comms but they get their
> > data from the single app server
> > So you have the app servers dealing with all the TCP IO, translating
> > from stored to html etc etc and the data server just doing the data.
> >
> > this is due to the history of Cach suporting large, distributed
> > systems - they have a lot of experience in doing this
> >
> >
> >
> >>12) i can understand from intersystem's point of view, it's beneficial
to
> >>sell cache not just as a standalone db product, but as a whole suite of
> >>solutions: db server, app server, OO, csp, dev/design tool (uml?), etc.
> >
> > This is not quite true - Cache does what it does, the db/app server
> > are a matter of configuration - ISC are a database company period
> > (well lets ignore Ensemble for the moment)
> > It lacks in the design tools (eg UML is only available from 3rd party
> > and it's only one way), source control (3rd party), a buggy IDE, CSP
> > excellent - but the object bind technology only really good for demo's
> >
> > My personal take on this is, that compared with a RDBMS it holds it's
> > own in performance (no more than that***) but to get best you need to
> > design things from the ground up in oo - and that's a completely
> > different story - but not so strange,eg I am involved with a client's
> > on-line system - the supplier is using mySql, nothing against that,
> > but the supplier is lacking intellectual power (oo or RDBMS), having a
> > few clients (successful) and now growing it's all breaking because
> > they have a faulty data model.
> > All I can say here is that it's easier to build a robust data model on
> > an oo environment than RDBMS
> >
> >
> > Just do it - but you have to climb the learning curve from RDBMS to oo
> >
> > Peter
> >
> > *** but it's far more robust
> >
> >
> >
No. 12
intersystems.public.cache:37933
Date: Tue, 17 May 2005 09:42:09 +0200
From: Frank Schob <frank.schob@nospam.be>
Subject: Re: newbie questions
Sukesh,
unfortunately I have to agree with David.
>>All this is very nice in theory. Unfortunately in practise it is
>>somewhat different. You must remember Cache is not by its nature an
>>Object Oriented programming language. This has been grafted ontop of a
>>totally untyped (ie everything is just a string or an array) language.
>
>
> I think, InterSystems have never claimed Cach・to be a pure object-oriented
> database. They have called it the post-relational database.
> Yes, they say Cach・ObjectScript (as the name implies) is an object
> programming language designed for rapidly developing complex business
> applications
The intersystems marketing points out the object data storage and access in its flyers. So they were able to argue our management of using Cache.
See the web sites of intersystem.
>
>>I advise you not to use the OO features, especially inheritance, any
>>more than you have to. I have spent a couple years maintaining a system
>>that makes extensive use of features like this and it is an absolute
>>nightmare.
>
>
> I am sure you are aware of the more horrible nightmares others have in
> maintaining relational databases (what with fulltime & highly paid DBAs).
> IMO, maintaining a Cach・based system is much easier than the RDBMSs.
I am not sure which RDBMs you mean. And I can not claim that Cache is a less expensive DBMS, especially if you need more than 200 licenses.
>
> My personal preference is not inheritance of the class definitions ( I do
> not even use them), but inheritance & hierarchies of the data.
>
>
>>I agree totally about needing a good design. It makes the world of
>>difference.
>
>
> May be the system you are maintaining was not designed properly, hence the
> nightmare.
Your statement: "maintaining a Cach・based system is much easier than the RDBMSs"
>
>
>>As for performance, you can get an amazing amounts of speed out of cache
>>but to do this you generally have to define your own storage and use the
>>classes as just wrappers. You definately have to know what you're doing
>
>
> Even default storage, and of course one has to know what one is doing, gives
> you superb performance.
I can neither confirm or disprove your subjective conclusion, cause I havent seen an independent, compareable performance test. But my experience is "it depends.". As developer I must say its my nightmare too, but I earn my salary with it.
It's nice to see that your experience are more positiv. But please consider: We use Cache more as an database (with object storage and access) than as an web application development tool.
And finally congratulations to your very good cache-basedc web site
http://personal.vsnl.com/sukesh_hoogan .
Frank
intersystems.public.cache:37933
Date: Tue, 17 May 2005 09:42:09 +0200
From: Frank Schob <frank.schob@nospam.be>
Subject: Re: newbie questions
Sukesh,
unfortunately I have to agree with David.
>>All this is very nice in theory. Unfortunately in practise it is
>>somewhat different. You must remember Cache is not by its nature an
>>Object Oriented programming language. This has been grafted ontop of a
>>totally untyped (ie everything is just a string or an array) language.
>
>
> I think, InterSystems have never claimed Cach・to be a pure object-oriented
> database. They have called it the post-relational database.
> Yes, they say Cach・ObjectScript (as the name implies) is an object
> programming language designed for rapidly developing complex business
> applications
The intersystems marketing points out the object data storage and access in its flyers. So they were able to argue our management of using Cache.
See the web sites of intersystem.
>
>>I advise you not to use the OO features, especially inheritance, any
>>more than you have to. I have spent a couple years maintaining a system
>>that makes extensive use of features like this and it is an absolute
>>nightmare.
>
>
> I am sure you are aware of the more horrible nightmares others have in
> maintaining relational databases (what with fulltime & highly paid DBAs).
> IMO, maintaining a Cach・based system is much easier than the RDBMSs.
I am not sure which RDBMs you mean. And I can not claim that Cache is a less expensive DBMS, especially if you need more than 200 licenses.
>
> My personal preference is not inheritance of the class definitions ( I do
> not even use them), but inheritance & hierarchies of the data.
>
>
>>I agree totally about needing a good design. It makes the world of
>>difference.
>
>
> May be the system you are maintaining was not designed properly, hence the
> nightmare.
Your statement: "maintaining a Cach・based system is much easier than the RDBMSs"
>
>
>>As for performance, you can get an amazing amounts of speed out of cache
>>but to do this you generally have to define your own storage and use the
>>classes as just wrappers. You definately have to know what you're doing
>
>
> Even default storage, and of course one has to know what one is doing, gives
> you superb performance.
I can neither confirm or disprove your subjective conclusion, cause I havent seen an independent, compareable performance test. But my experience is "it depends.". As developer I must say its my nightmare too, but I earn my salary with it.
It's nice to see that your experience are more positiv. But please consider: We use Cache more as an database (with object storage and access) than as an web application development tool.
And finally congratulations to your very good cache-basedc web site
http://personal.vsnl.com/sukesh_hoogan .
Frank
No. 13
intersystems.public.cache:37937
Date: Tue, 17 May 2005 10:10:15 +0100
From: David Arkell <david.arkell@mtivity.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
Newsgroups: intersystems.public.cache
Subject: Re: newbie questions
Sukesh,
Thanks for the sympathy.
I agree with most of what you said. Let me say from the start that I don't blame cache entirely for the mess i have to deal with. I think the initial programmers found what they thought were really nifty cool things they could do and just did them all regardless of whether it was appropriate or not.
That being said there are some real problems with cache classes. When you have enough classes, persistant and otherwise, cache cannot figure out dependancies propperly. I've lost count of the amount of times we had to compile the entire application because of this. And our application takes over an hour to compile.
I come from a java background and I guess I just got used to dependancies and all that other stuff being resolved automatically. (I used apache ant to do the compilation.)
And the other thing about classes. They all compile down to mac code. I just adds a lot of extra code to make it mimic what objects are supposed to do. This affects performance dramatically. The more I program directly at the mac level the less time I have for classes.
You are right about the default storage. I think its pretty good too. I think the major advantage of defining your own is the ability to design your own indices. For example we have an index on username that also contains the password, kinda like this.
^UserGlobal("username-index","user@company.com",[rowID])="password"
With this method when someone tries to log into our application we can check the username/password directly without actually querying the users table. I understand that this is a small thing but its the only simple example i can think of right now.
Of course defining your own storage has its own problems but nothing is perfect.
Regards,
David
intersystems.public.cache:37937
Date: Tue, 17 May 2005 10:10:15 +0100
From: David Arkell <david.arkell@mtivity.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
Newsgroups: intersystems.public.cache
Subject: Re: newbie questions
Sukesh,
Thanks for the sympathy.
I agree with most of what you said. Let me say from the start that I don't blame cache entirely for the mess i have to deal with. I think the initial programmers found what they thought were really nifty cool things they could do and just did them all regardless of whether it was appropriate or not.
That being said there are some real problems with cache classes. When you have enough classes, persistant and otherwise, cache cannot figure out dependancies propperly. I've lost count of the amount of times we had to compile the entire application because of this. And our application takes over an hour to compile.
I come from a java background and I guess I just got used to dependancies and all that other stuff being resolved automatically. (I used apache ant to do the compilation.)
And the other thing about classes. They all compile down to mac code. I just adds a lot of extra code to make it mimic what objects are supposed to do. This affects performance dramatically. The more I program directly at the mac level the less time I have for classes.
You are right about the default storage. I think its pretty good too. I think the major advantage of defining your own is the ability to design your own indices. For example we have an index on username that also contains the password, kinda like this.
^UserGlobal("username-index","user@company.com",[rowID])="password"
With this method when someone tries to log into our application we can check the username/password directly without actually querying the users table. I understand that this is a small thing but its the only simple example i can think of right now.
Of course defining your own storage has its own problems but nothing is perfect.
Regards,
David
No. 14
intersystems.public.cache:37940
From: Peter Cooper <pfc@xisltd.demon.co.uk>
Subject: Re: newbie questions
Date: Tue, 17 May 2005 15:48:52 +0100
David
Just a few comments
>I agree with most of what you said. Let me say from the start that I
>don't blame cache entirely for the mess i have to deal with. I think the
>initial programmers found what they thought were really nifty cool
>things they could do and just did them all regardless of whether it was
>appropriate or not.
Totally agree - you can make some right messes - but with experience (I have got the grey hairs) you can do just the right amout of oo - ISC fell into this trap with their implimentation of streams where there was so much multiple inheritance that I for one could not undertand it
>That being said there are some real problems with cache classes. When
>you have enough classes, persistant and otherwise, cache cannot figure
>out dependancies propperly. I've lost count of the amount of times we
>had to compile the entire application because of this. And our
>application takes over an hour to compile.
Yes this is a real pain
>And the other thing about classes. They all compile down to mac code. I
>just adds a lot of extra code to make it mimic what objects are supposed
>to do. This affects performance dramatically. The more I program
>directly at the mac level the less time I have for classes.
my rule of thumb is that object access is around 10 times slower than raw access - but have a look at embedded SQL - this can be around 2 times slower than raw access for simple operations but when you get to a comlex insert/update there seems to be little difference between embedded SQL and raw access
>You are right about the default storage. I think its pretty good too. I
>think the major advantage of defining your own is the ability to design
>your own indices.
The problem I have with this is that you cannot use bit map indices and these are a real performance boost
>For example we have an index on username that also
>contains the password, kinda like this.
>
>^UserGlobal("username-index","user@company.com",[rowID])="password"
but you can define exactly this structure with objects
Property pUserID As %String;
Property pPassword As %String;
Index idxUser On pUserID [ Data = pPassword ];
Peter
intersystems.public.cache:37940
From: Peter Cooper <pfc@xisltd.demon.co.uk>
Subject: Re: newbie questions
Date: Tue, 17 May 2005 15:48:52 +0100
David
Just a few comments
>I agree with most of what you said. Let me say from the start that I
>don't blame cache entirely for the mess i have to deal with. I think the
>initial programmers found what they thought were really nifty cool
>things they could do and just did them all regardless of whether it was
>appropriate or not.
Totally agree - you can make some right messes - but with experience (I have got the grey hairs) you can do just the right amout of oo - ISC fell into this trap with their implimentation of streams where there was so much multiple inheritance that I for one could not undertand it
>That being said there are some real problems with cache classes. When
>you have enough classes, persistant and otherwise, cache cannot figure
>out dependancies propperly. I've lost count of the amount of times we
>had to compile the entire application because of this. And our
>application takes over an hour to compile.
Yes this is a real pain
>And the other thing about classes. They all compile down to mac code. I
>just adds a lot of extra code to make it mimic what objects are supposed
>to do. This affects performance dramatically. The more I program
>directly at the mac level the less time I have for classes.
my rule of thumb is that object access is around 10 times slower than raw access - but have a look at embedded SQL - this can be around 2 times slower than raw access for simple operations but when you get to a comlex insert/update there seems to be little difference between embedded SQL and raw access
>You are right about the default storage. I think its pretty good too. I
>think the major advantage of defining your own is the ability to design
>your own indices.
The problem I have with this is that you cannot use bit map indices and these are a real performance boost
>For example we have an index on username that also
>contains the password, kinda like this.
>
>^UserGlobal("username-index","user@company.com",[rowID])="password"
but you can define exactly this structure with objects
Property pUserID As %String;
Property pPassword As %String;
Index idxUser On pUserID [ Data = pPassword ];
Peter
No. 15
intersystems.public.cache:37941
From: "Sukesh Hoogan" <sukeshhoogan@NOSPAMvsnl.com>
Subject: Re: newbie questions
Date: Tue, 17 May 2005 22:43:55 +0530
Frank
It has been illuminating discussion so far (that is one of the objectives
of such forums).
See in-line
Regards
Sukesh Hoogan
"Frank Schob" <frank.schob@nospam.be> wrote in message
news:4289a1ed.0@info2.kinich.com...
> Sukesh,
> unfortunately I have to agree with David.
>
> >>All this is very nice in theory. Unfortunately in practise it is
> >>somewhat different. You must remember Cache is not by its nature an
> >>Object Oriented programming language. This has been grafted ontop of a
> >>totally untyped (ie everything is just a string or an array) language.
> >
> >
> > I think, InterSystems have never claimed Cach・to be a pure
object-oriented
> > database. They have called it the post-relational database.
> > Yes, they say Cach・ObjectScript (as the name implies) is an object
> > programming language designed for rapidly developing complex business
> > applications
> The intersystems marketing points out the object data storage and access
> in its flyers. So they were able to argue our management of using Cache.
> See the web sites of intersystem.
>
> >
> >>I advise you not to use the OO features, especially inheritance, any
> >>more than you have to. I have spent a couple years maintaining a system
> >>that makes extensive use of features like this and it is an absolute
> >>nightmare.
> >
> >
> > I am sure you are aware of the more horrible nightmares others have in
> > maintaining relational databases (what with fulltime & highly paid
DBAs).
> > IMO, maintaining a Cach・based system is much easier than the RDBMSs.
> I am not sure which RDBMs you mean.
Oracle, SQLServer, etc. Otherwise they would not need fultime DBAs.
>And I can not claim that Cache is a less expensive DBMS, especially if you need more than 200 licenses.
Now I would not be able to comment on it. InterSystems is so paranoidly secretive about its pricing model.
> >
> > My personal preference is not inheritance of the class definitions ( I
do
> > not even use them), but inheritance & hierarchies of the data.
> >>I agree totally about needing a good design. It makes the world of
> >>difference.
> >
> >
> > May be the system you are maintaining was not designed properly, hence the
> > nightmare.
> Your statement: "maintaining a Cach・based system is much easier than
> the RDBMSs"
> >
> >
> >>As for performance, you can get an amazing amounts of speed out of cache
> >>but to do this you generally have to define your own storage and use the
> >>classes as just wrappers. You definately have to know what you're doing
> >
> >
> > Even default storage, and of course one has to know what one is doing, gives
> > you superb performance.
> I can neither confirm or disprove your subjective conclusion, cause I
> havent seen an independent, compareable performance test. But my
> experience is "it depends.". As developer I must say its my nightmare
> too, but I earn my salary with it.
I only said superb perforamnce, did not say better than custom storage.
Having said that, I am loathe to change Cach・s default settings / parameters / design, as I believe with these defaults, Cach・performance is optimal (nobody knows Cach・better than InterSystems and they set the defaults).
The fact that Cach・allows you to override many/most of the defaults is another matter.
> It's nice to see that your experience are more positiv. But please
> consider: We use Cache more as an database (with object storage and
> access) than as an web application development tool.
> And finally congratulations to your very good cache-basedc web site
> http://personal.vsnl.com/sukesh_hoogan .
Thank youi
> Frank
intersystems.public.cache:37941
From: "Sukesh Hoogan" <sukeshhoogan@NOSPAMvsnl.com>
Subject: Re: newbie questions
Date: Tue, 17 May 2005 22:43:55 +0530
Frank
It has been illuminating discussion so far (that is one of the objectives
of such forums).
See in-line
Regards
Sukesh Hoogan
"Frank Schob" <frank.schob@nospam.be> wrote in message
news:4289a1ed.0@info2.kinich.com...
> Sukesh,
> unfortunately I have to agree with David.
>
> >>All this is very nice in theory. Unfortunately in practise it is
> >>somewhat different. You must remember Cache is not by its nature an
> >>Object Oriented programming language. This has been grafted ontop of a
> >>totally untyped (ie everything is just a string or an array) language.
> >
> >
> > I think, InterSystems have never claimed Cach・to be a pure
object-oriented
> > database. They have called it the post-relational database.
> > Yes, they say Cach・ObjectScript (as the name implies) is an object
> > programming language designed for rapidly developing complex business
> > applications
> The intersystems marketing points out the object data storage and access
> in its flyers. So they were able to argue our management of using Cache.
> See the web sites of intersystem.
>
> >
> >>I advise you not to use the OO features, especially inheritance, any
> >>more than you have to. I have spent a couple years maintaining a system
> >>that makes extensive use of features like this and it is an absolute
> >>nightmare.
> >
> >
> > I am sure you are aware of the more horrible nightmares others have in
> > maintaining relational databases (what with fulltime & highly paid
DBAs).
> > IMO, maintaining a Cach・based system is much easier than the RDBMSs.
> I am not sure which RDBMs you mean.
Oracle, SQLServer, etc. Otherwise they would not need fultime DBAs.
>And I can not claim that Cache is a less expensive DBMS, especially if you need more than 200 licenses.
Now I would not be able to comment on it. InterSystems is so paranoidly secretive about its pricing model.
> >
> > My personal preference is not inheritance of the class definitions ( I
do
> > not even use them), but inheritance & hierarchies of the data.
> >>I agree totally about needing a good design. It makes the world of
> >>difference.
> >
> >
> > May be the system you are maintaining was not designed properly, hence the
> > nightmare.
> Your statement: "maintaining a Cach・based system is much easier than
> the RDBMSs"
> >
> >
> >>As for performance, you can get an amazing amounts of speed out of cache
> >>but to do this you generally have to define your own storage and use the
> >>classes as just wrappers. You definately have to know what you're doing
> >
> >
> > Even default storage, and of course one has to know what one is doing, gives
> > you superb performance.
> I can neither confirm or disprove your subjective conclusion, cause I
> havent seen an independent, compareable performance test. But my
> experience is "it depends.". As developer I must say its my nightmare
> too, but I earn my salary with it.
I only said superb perforamnce, did not say better than custom storage.
Having said that, I am loathe to change Cach・s default settings / parameters / design, as I believe with these defaults, Cach・performance is optimal (nobody knows Cach・better than InterSystems and they set the defaults).
The fact that Cach・allows you to override many/most of the defaults is another matter.
> It's nice to see that your experience are more positiv. But please
> consider: We use Cache more as an database (with object storage and
> access) than as an web application development tool.
> And finally congratulations to your very good cache-basedc web site
> http://personal.vsnl.com/sukesh_hoogan .
Thank youi
> Frank
No. 16
intersystems.public.cache:37942
From: "Sukesh Hoogan" <sukeshhoogan@NOSPAMvsnl.com>
Subject: Re: newbie questions
Date: Tue, 17 May 2005 22:44:01 +0530
Frank, David & Peter
What I was trying to say that no DBMS is perfect (in fact, there is no such thing as perfect software), each one has it own sets of glitches, bugs and what have you and then there are its positives.
See in-line also
Regards
Sukesh Hoogan
e-Linear Enterprise Solutiuons.
Bombay (India)
http://personal.vsnl.com/sukesh_hoogan
"Peter Cooper" <pfc@xisltd.demon.co.uk> wrote in message
news:ag0k819onf3fbs5uu1do77unb1r7fl812e@4ax.com...
> David
>
> Just a few comments
>
> >I agree with most of what you said. Let me say from the start that I
> >don't blame cache entirely for the mess i have to deal with. I think the
> >initial programmers found what they thought were really nifty cool
> >things they could do and just did them all regardless of whether it was
> >appropriate or not.
My guess would be that the intial programmers/designers were still too steeped into relational database world athen nd not sufficiently aware of the object oriented concepts (to whatever level Cach・has to offer).
Yes, we all sometimes do try to do things/incorporate code that are/is cool but not appropriate, just to tell oneself "What a clever chap I am"
> Totally agree - you can make some right messes - but with experience
> (I have got the grey hairs) you can do just the right amout of oo -
> ISC fell into this trap with their implimentation of streams where
> there was so much multiple inheritance that I for one could not
> undertand it
> >That being said there are some real problems with cache classes. When
> >you have enough classes, persistant and otherwise, cache cannot figure
> >out dependancies propperly. I've lost count of the amount of times we
> >had to compile the entire application because of this. And our
> >application takes over an hour to compile.
That is why I avoid using many of he Cach・s object concepts - eg Lists and Arrays. Here the relational concepts + Cach・s object reference works much better.
> Yes this is a real pain
> >And the other thing about classes. They all compile down to mac code. I
> >just adds a lot of extra code to make it mimic what objects are supposed
> >to do. This affects performance dramatically. The more I program
> >directly at the mac level the less time I have for classes.
Yes, I agree.
> my rule of thumb is that object access is around 10 times slower than
> raw access - but have a look at embedded SQL - this can be around 2
> times slower than raw access for simple operations but when you get to
> a comlex insert/update there seems to be little difference between
> embedded SQL and raw access
Hence I use a combination of all three - Object Access / Direct and SQL.
> >You are right about the default storage. I think its pretty good too. I
> >think the major advantage of defining your own is the ability to design
> >your own indices.
> The problem I have with this is that you cannot use bit map indices
> and these are a real performance boost
>
> >For example we have an index on username that also
> >contains the password, kinda like this.
> >
> >^UserGlobal("username-index","user@company.com",[rowID])="password"
IMO, one would do such a thing if one were to migrate from a RDBMS using the exact schema and code. Peter has shown how it should be in Cach・
> but you can define exactly this structure with objects
>
> Property pUserID As %String;
> Property pPassword As %String;
> Index idxUser On pUserID [ Data = pPassword ];
> Peter
>
intersystems.public.cache:37942
From: "Sukesh Hoogan" <sukeshhoogan@NOSPAMvsnl.com>
Subject: Re: newbie questions
Date: Tue, 17 May 2005 22:44:01 +0530
Frank, David & Peter
What I was trying to say that no DBMS is perfect (in fact, there is no such thing as perfect software), each one has it own sets of glitches, bugs and what have you and then there are its positives.
See in-line also
Regards
Sukesh Hoogan
e-Linear Enterprise Solutiuons.
Bombay (India)
http://personal.vsnl.com/sukesh_hoogan
"Peter Cooper" <pfc@xisltd.demon.co.uk> wrote in message
news:ag0k819onf3fbs5uu1do77unb1r7fl812e@4ax.com...
> David
>
> Just a few comments
>
> >I agree with most of what you said. Let me say from the start that I
> >don't blame cache entirely for the mess i have to deal with. I think the
> >initial programmers found what they thought were really nifty cool
> >things they could do and just did them all regardless of whether it was
> >appropriate or not.
My guess would be that the intial programmers/designers were still too steeped into relational database world athen nd not sufficiently aware of the object oriented concepts (to whatever level Cach・has to offer).
Yes, we all sometimes do try to do things/incorporate code that are/is cool but not appropriate, just to tell oneself "What a clever chap I am"
> Totally agree - you can make some right messes - but with experience
> (I have got the grey hairs) you can do just the right amout of oo -
> ISC fell into this trap with their implimentation of streams where
> there was so much multiple inheritance that I for one could not
> undertand it
> >That being said there are some real problems with cache classes. When
> >you have enough classes, persistant and otherwise, cache cannot figure
> >out dependancies propperly. I've lost count of the amount of times we
> >had to compile the entire application because of this. And our
> >application takes over an hour to compile.
That is why I avoid using many of he Cach・s object concepts - eg Lists and Arrays. Here the relational concepts + Cach・s object reference works much better.
> Yes this is a real pain
> >And the other thing about classes. They all compile down to mac code. I
> >just adds a lot of extra code to make it mimic what objects are supposed
> >to do. This affects performance dramatically. The more I program
> >directly at the mac level the less time I have for classes.
Yes, I agree.
> my rule of thumb is that object access is around 10 times slower than
> raw access - but have a look at embedded SQL - this can be around 2
> times slower than raw access for simple operations but when you get to
> a comlex insert/update there seems to be little difference between
> embedded SQL and raw access
Hence I use a combination of all three - Object Access / Direct and SQL.
> >You are right about the default storage. I think its pretty good too. I
> >think the major advantage of defining your own is the ability to design
> >your own indices.
> The problem I have with this is that you cannot use bit map indices
> and these are a real performance boost
>
> >For example we have an index on username that also
> >contains the password, kinda like this.
> >
> >^UserGlobal("username-index","user@company.com",[rowID])="password"
IMO, one would do such a thing if one were to migrate from a RDBMS using the exact schema and code. Peter has shown how it should be in Cach・
> but you can define exactly this structure with objects
>
> Property pUserID As %String;
> Property pPassword As %String;
> Index idxUser On pUserID [ Data = pPassword ];
> Peter
>
＞好日さん
楽しい？トピックありがとうございます(笑)。
DEVCON2005にもにたようなテーマがありますね(これもおもしろいです)。
Design Considerations - Relational, Object, or Direct Access?
http://www.intersystems.com/devcon2005/tuesday/UMNIKOV%20-%20DesignConsiderations.zip
DEVCON2005をみてみると以前ほどオブジェクト一辺倒ではなくて、グローバル変数という言葉がチラチラ見える(以前は意識的に隠していた？)ようにおもいます(ＤＢはグローバル変数でアクセスはいろんな方法ができますみたいな文脈でですが)。
ＲＤＢやＯＯＤＢの制限？を当たり前に受け入れている人だと、グローバルの自由度を理解できないのかもしれませんねー。
Using InterSystems' ADO.NET Managed Provider
http://www.intersystems.com/devcon2005/academy/Using%20InterSystems%20ADO.NET%20Managed%20Provider.zip
インターシステムズのフィルさんは、WebServiceでの接続デモをを用意してくれてますね。
WebServiceを使うとMでコントロール出来る部分が(ObjectやSQLアクセスに比べて)多いように思います(ねらい目？、笑)。
Mに他のものを取り入れる方向もいいですが、Mの良さを広げていく方向も期待したいです。例えばMicrosoftのCLR上でMUMPSを書けるようにするとか・・・
楽しい？トピックありがとうございます(笑)。
DEVCON2005にもにたようなテーマがありますね(これもおもしろいです)。
Design Considerations - Relational, Object, or Direct Access?
http://www.intersystems.com/devcon2005/tuesday/UMNIKOV%20-%20DesignConsiderations.zip
DEVCON2005をみてみると以前ほどオブジェクト一辺倒ではなくて、グローバル変数という言葉がチラチラ見える(以前は意識的に隠していた？)ようにおもいます(ＤＢはグローバル変数でアクセスはいろんな方法ができますみたいな文脈でですが)。
ＲＤＢやＯＯＤＢの制限？を当たり前に受け入れている人だと、グローバルの自由度を理解できないのかもしれませんねー。
Using InterSystems' ADO.NET Managed Provider
http://www.intersystems.com/devcon2005/academy/Using%20InterSystems%20ADO.NET%20Managed%20Provider.zip
インターシステムズのフィルさんは、WebServiceでの接続デモをを用意してくれてますね。
WebServiceを使うとMでコントロール出来る部分が(ObjectやSQLアクセスに比べて)多いように思います(ねらい目？、笑)。
Mに他のものを取り入れる方向もいいですが、Mの良さを広げていく方向も期待したいです。例えばMicrosoftのCLR上でMUMPSを書けるようにするとか・・・
つーさん
>DEVCON2005にもにたようなテーマがありますね(これもおもしろいです)。
>Design Considerations - Relational, Object, or Direct Access?
>DEVCON2005をみてみると以前ほどオブジェクト一辺倒ではなくて、
>グローバル変数という言葉がチラチラ見える(以前は意識的に隠していた？)
>ようにおもいます(ＤＢはグローバル変数でアクセスはいろんな方法ができますみたいな文脈でですが)。
その通りです。
Design Considerationsのスライド２２ページの３つのアクセス性能比較
Adding 100000 records/objects to the database
で Direct 0.6 ... Object 11.6
19.3倍も違うと考えますよね。
とくに、Webアプリでは、ObjectのOpen(メモリー展開-インスタンス作成）、Close（インスタンス開放）を毎回、セッション毎やる無駄はおおきい。
１２ページの Direct Access のコード例
write $ListGet(^User.ItemsD(1),2)
は、デフォルトStorage（InterSystemsお任せ）を前提にしていて、
Data is always stored in Globals
と云われても、デフォルトStorageの内部構造の仕様がOpenされていないし、されても AS IS ベースでしょうから、このようなコードをユーザがやると"反則"じゃないのかなぁ？！
２３ぺ−ジで、Direct Access
Direct structures are not projected as Tables and Classes(SQLStorage as workaround)
Direct Access(=Mコードでのグローバルアクセス)は当然、構造のメタ情報を持たない（宣言なし）のため、SQLの為のリレーションTableアクセスやオブジェクトClassアクセスは出来ない（SQLStorageはworkaround）。
SQLStorageの言葉が初めて出て来ました。
Direct AccessとSQLとオブジェクトの３つのアクセスを“Smart”に行うためには、workaround でなく SQLStorage しかないと思いますがね？
デフォルトStorageの内部仕様を公開し将来も保障してくれれば別ですがね。
３２ページ SQL Storage で
Documentation and Manuals available from IS
とあり、これレガシーとなってますよ。
そんな訳で、結論で
Learn to combine access methods in your application “Smart” way
とあるが、どう“Smart”にしたらいいのか、M（UMPS)グローバルの良さ（速さ、透明性、相当複雑な構造も持てる）を知っているものにとっては迷うとこですね。
>DEVCON2005にもにたようなテーマがありますね(これもおもしろいです)。
>Design Considerations - Relational, Object, or Direct Access?
>DEVCON2005をみてみると以前ほどオブジェクト一辺倒ではなくて、
>グローバル変数という言葉がチラチラ見える(以前は意識的に隠していた？)
>ようにおもいます(ＤＢはグローバル変数でアクセスはいろんな方法ができますみたいな文脈でですが)。
その通りです。
Design Considerationsのスライド２２ページの３つのアクセス性能比較
Adding 100000 records/objects to the database
で Direct 0.6 ... Object 11.6
19.3倍も違うと考えますよね。
とくに、Webアプリでは、ObjectのOpen(メモリー展開-インスタンス作成）、Close（インスタンス開放）を毎回、セッション毎やる無駄はおおきい。
１２ページの Direct Access のコード例
write $ListGet(^User.ItemsD(1),2)
は、デフォルトStorage（InterSystemsお任せ）を前提にしていて、
Data is always stored in Globals
と云われても、デフォルトStorageの内部構造の仕様がOpenされていないし、されても AS IS ベースでしょうから、このようなコードをユーザがやると"反則"じゃないのかなぁ？！
２３ぺ−ジで、Direct Access
Direct structures are not projected as Tables and Classes(SQLStorage as workaround)
Direct Access(=Mコードでのグローバルアクセス)は当然、構造のメタ情報を持たない（宣言なし）のため、SQLの為のリレーションTableアクセスやオブジェクトClassアクセスは出来ない（SQLStorageはworkaround）。
SQLStorageの言葉が初めて出て来ました。
Direct AccessとSQLとオブジェクトの３つのアクセスを“Smart”に行うためには、workaround でなく SQLStorage しかないと思いますがね？
デフォルトStorageの内部仕様を公開し将来も保障してくれれば別ですがね。
３２ページ SQL Storage で
Documentation and Manuals available from IS
とあり、これレガシーとなってますよ。
そんな訳で、結論で
Learn to combine access methods in your application “Smart” way
とあるが、どう“Smart”にしたらいいのか、M（UMPS)グローバルの良さ（速さ、透明性、相当複雑な構造も持てる）を知っているものにとっては迷うとこですね。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
MUMPS好き好き。 更新情報
-
最新のアンケート
-
まだ何もありません
-
MUMPS好き好き。のメンバーはこんなコミュニティにも参加しています
人気コミュニティランキング
- 1位
- パニック障害とうつ病
- 8435人
- 2位
- 音楽が無いと生きていけない
- 196001人
- 3位
- マイミク募集はここで。
- 89505人