Re: Mapped and memory based data files

aplisfast wrote:

> Thanks for your response.
>
> J. Clarke wrote:
>> aplisfast wrote:
>>
>> > I have researched a few SQL type database applications but can not seem
>> > to find out how they would excelerate speed to compete with memory
>> > based database solutions.
>>
>> You seem to have some misconceptions about the nature of SQL. SQL is a
>> query language--it is to a substantial extent independent of the storage
>> architecture. Most commercially available database engines that support
>> SQL are disk based, but nothing inherent in SQL requires that they be so
>> and the Oracle/Times Ten product that you mention below is an example of
>> one that is memory-based and supports SQL.
>>
>> > APL is fast but for real time application
>> > where speed is of critical importance -- component and native files
>> > have disadvantages related to their disk operations.
>>
>> If it's memory based then component and native files aren't relevant now
>> are
>> they? Except for backup of course.
>>
>> > J is following K into memory based computing -- which is an area where
>> > users pay dearly for speed advantages. I believe connecting APL or for
>> > that matter any powerful array programming languages to in-memory
>> > databases will provide lucrative niche applications.
>
> Increased speed is a primary reason user pay many time more for K and
> Times Ten.
>
>> How will connecting them into "in-memory databases" be different from
>> connecting them to any other kind of database?
>>
>> > It's interestiing that just a powerful array based language and
>> > in-memory database can run upwards of 100K.. The follow article
>> > discussed a recent sale of TimesTen which is one of the few in-memory
>> > databases. Their purchase by Oracle suggest that the demand in-memory
>> > databases is likely to increase:
>> >
>> > http://www.itworld.com/AppDev/13/051010oracledb/
>
> You don't have to be a large organization to look for loopholes to
> close the speed gap! You just have to figure a loophole to arrive at a
> similar solution.

But why would a _small_ organization need that kind of performance?

In any case there are no "loopholes". You buy code or you write code--both
have costs. APL might be good for this purpose, however since the goal is
not simply to store data in memory but to provide multiuser access to it
and maintain its integrity in case of power failure or OS crash or other
eventuality that clears the contents of memory, and since APL does not have
those features natively, one wonders whether APL will in fact be any better
for this particular purpose than any other language--its ability to manage
data as arrays in memory would be helpful but might not be the deciding
factor.

>> Why do you find that "interesting"? If your organization is large enough
>> to need the capabilities that is not a lot of money.
>>
>> > I don't know the J language or the extent of their memory based
>> > solutions but I'm really surprised they are entering this area on such
>> > a cost effective basis. This means it possible to derive in-memory
>> > databases at reasonable cost. I would like to hear from anyone who has
>> > found a cost effective in-memory database.
>
>> No doubt eventually MySQL will have in-memory capability. I don't know
>> what gives you the idea that any particular type of software has to have
>> any particular cost associated with it.
>
> Eventually is a time dependent word. "Right now" people are paying
> anywhere from 10 to 40K for per CPU to gain significant speed
> advantages today. Same demand - supply issue that we've seen since the
> intro of PC's, operating systems, etc.

Yes, they are, because (a) they want the support that Oracle
provides--they're still paying Oracle prices for Oracle software even
though there are quite adequate open source SQL databases and (b) there
isn't much in the way of inexpensive software that does this particular
task.

> Just because some loophole to the problem provides a cost effective
> solution doesn't mean prices will decrease if most are unaware of it.

There isn't any "loophole to the problem". Eventually the Open Source
community will get around to providing this capability but it won't be
because they found a "loophole" it will be because a group of skilled
programmers donated a good deal of their time to the effort.

> The simplest loophold may be to point out the potential in-memory
> databases to array processing languages and let the competition
> decrease cost.

I'm sorry, but I'm having trouble parsing that sentence. Do you believe
that array processing languages are somehow equivalent to "in-memory
databases"?

> This is generally what "eventually" happens.

What _eventually_ happens is that somebody goes after a mass market--if they
achieve market dominance then the price comes down, if they don't but make
enough to stay in business then you end up with a fragmented market, if
they fail outright then nothing changes.

> Since I
> don't have a huge database to deal with -- so I would be very happy
> finding a J or Dyalog type memory solution -- even if it's a third
> party product.

How many users have to access this database and what response time do you
need?

>
> Thanks for "all" responses to my post. Even the hardware side is
> helpful.
>
>> > aplisfast wrote:
>> >> Thanks for your response. I'm using APL+Win from APL2000.
>> >> I will explore the benefits of ADO. I have MDAC2.8 & SDK.
>> >>
>> >> AA2e72E wrote:
>> >> > I am not sure whether you mean APL+Win from APL2000 or whether you
>> >> > are referring to the APL from Sharp.
>> >> >
>> >> > APL+Win does not have a facility for memory mapped files. Consider
>> >> > using the ADO stream object; in order to investigate its suitability
>> >> > for your purposes, download MDAC 2.8 and the SDK from Microsoft.
>>
>> --
>> --John
>> to email, dial "usenet" and validate
>> (was jclarke at eye bee em dot net)

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
.

Relevant Pages

  • Re: Multi-Channel Raid VS SAN Storage
    ... The idea of keeping the database in memory is appealing, ... Our report SPs are vry tempDB and memory intensive. ... Probably because our SQL server only has 3 GB of RAM. ... needs it's own SAN device, or at least a dedicated IO channel on the SAN. ...
    (microsoft.public.sqlserver.setup)
  • Re: CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to
    ... Go to the Database tab and click on the browse button next to the connection string. ... In the New Database Reference dialog, enter the details for the database where you want to deploy the assembly and create the user defined aggregate. ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to meth
    ... Now register the assembly and the aggregate in the SQL Server database you want ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... But SQL does not have a pointer data type or the ... > being told to design a database. ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • Re: DBMS and lisp, etc.
    ... Naively implemented with SQL, again for 10 ... (1 query for the initial orders, 1 query for each order for its ... soon as you upgrade to the SQL database. ... (eq (order-customer orderA) ...
    (comp.lang.lisp)
Loading