Intense network systems like our clients cannot work with database calls. They are too slow and do not scale. They either reach a cost or a performance ceiling.
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 16, 2010, at 5:55 AM, Patricia Shanahan <p...@acm.org> wrote: > 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 > > >
