MICHAEL MCGRADY wrote:
Patricia,
If you don't mind, I am going to argue for sticking to the machines,
but answer your question roughly at the end.
I don't mind machines, as long as they get somewhat quantified. It was
"machines a minute" that really gave me trouble. However, there are
machines and machines, so I would rather think in terms of transaction
rates.
The questions about either memory use or connections or transactions
are stressors leading to the question and the urgency whether or not
something must scale, but they have nothing or very little to do with
whether it will scale.
If we try to involve multiple machines, then we will discover
frequently that, even if we do not need to scale, we cannot because,
for example, of Amdahl's Theorem. If we cannot go to multiple
machines as a practical matter, we cannot scale no matter what
(ceteris paribus). If we can, then we will find, it is our
experience, that we can scale no matter what (ceteris paribus).
Scaling is exactly the reason why I think the current FastList-based
design is seriously limited, and may need to be replaced by something
that indexes its data.
Outrigger turns a JavaSpace read into a linked
list scan of all the entries in the space for the required type. Not too
bad if the list rarely changes and is always small enough to fit in
cache. If it is big or changing, that is going to cause a lot of memory
traffic.
As implemented, it cannot be spread across machines very
effectively because the additional scanning due to one machine not
knowing that another has already found the entry would use up the added
scan power.
I think to scale it is going to need some sort of indexing, and as I
think about indexing for the sort of ad-hoc query that JavaSpaces face,
combined with frequent change, it starts looking very like maintaining
an indexed database table.
However, we should be able to do, say, hundreds of millions of
transactions in a day in real-time critical systems such as the FAA
or the stock market with data affinity and integrity and all the
other "ilities". If Outrigger cannot do this, it is of no interest
to us.
The current record for a relational database doing simple transactions
is 30 million transactions per minute (Oracle/SPARC TPC-C). Your mileage
may vary, but there is no inherent limit on relational database scaling
that puts a few hundred thousand transactions per minute out of reach.
MG
On Dec 14, 2010, at 9:48 PM, Patricia Shanahan wrote:
Please clarify "machines a minute". Can you express it e.g. in
transactions per minute?
Patricia
Mike McGrady wrote:
Linear - 7000 machines a minute, or more. Sent from my iPhone
Michael McGrady Principal investigator AF081_028 SBIR Chief
Architect Topia Technology, Inc Work 1.253.572.9712 Cel
1.253.720.3365 On Dec 14, 2010, at 2:04 PM, Patricia Shanahan
<p...@acm.org> wrote:
On 12/14/2010 1:49 PM, MICHAEL MCGRADY wrote:
On Dec 14, 2010, at 1:40 PM, Patricia Shanahan wrote:
...
If we made a persistent version use a relational database
to represent the space,
This would not be usable for us. This is too slow and does
not have the correct QCC features, especially scalability.
...
Could you put some numbers on what sort of scalability you
require?
Patricia
Michael McGrady Chief Architect Topia Technology, Inc. Cel
1.253.720.3365 Work 1.253.572.9712 extension 2037
mmcgr...@topiatechnology.com
