AlchemyDB – The world’s first integrated GraphDB + RDBMS + KV Store + Document Store
Jak Sprats
I am the author of AlchemyDB, and I figured this group is interested
in Nosql, and my most recent blog post covers a bunch of Nosql bases,
so I figured I would post here, and see if anyone wanted to read it.
Title: "AlchemyDB – The world’s first integrated GraphDB + RDBMS + KV
Store + Document Store"
http://jaksprats.wordpress.com/2012/02/28/lightweight-oltp-data-platform/
- jak
Bohu TANG
- jak
--
You received this message because you are subscribed to the Google Groups "NOSQL" group.
To post to this group, send email to nosql-di...@googlegroups.com.
To unsubscribe from this group, send email to nosql-discussi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nosql-discussion?hl=en.
Kingsley Idehen
> Title: "AlchemyDB – The world’s first integrated GraphDB + RDBMS + KV
> Store + Document Store"
> http://jaksprats.wordpress.com/2012/02/28/lightweight-oltp-data-platform/
to refute claim.
Multi Model DBMS technology has existed for a very long time. Long
before the year 2000.
--
Regards,
Kingsley Idehen
Founder& CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Jak Sprats
I guess because I am ignorant of said Multi Model DBMSes. What other
DB integrated a "GraphDB + RDBMS + KV Store + Document Store", I am
genuinely interested.
Also, having written this stuff, I know it's not rocket science, it's
just pretty difficult, my original title was "The creation of a Data
Platform" but I got feedback that that was too boring, so I went w/
the more ooh-la-la title ... so perhaps it is just a reflection of our
times :)
- jak
On Feb 29, 6:03 pm, Kingsley Idehen <kide...@openlinksw.com> wrote:
> On 2/29/12 1:23 AM, Bohu TANG wrote:> Title: "AlchemyDB – The world’s first integrated GraphDB + RDBMS + KV
> > Store + Document Store"
> Why can't you just announce our product without making what is an easy
> to refute claim.
>
> Multi Model DBMS technology has existed for a very long time. Long
> before the year 2000.
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder& CEO
> OpenLink Software
> Company Web:http://www.openlinksw.com
> Personal Weblog:http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile:https://plus.google.com/112399767740508618350/about
> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
> 2KViewDownload
Rob Tweed
Rob
--
You received this message because you are subscribed to the Google Groups "NOSQL" group.
To post to this group, send email to nosql-di...@googlegroups.com.
To unsubscribe from this group, send email to nosql-discussi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nosql-discussion?hl=en.
Rob Tweed
Director, M/Gateway Developments Ltd
http://www.mgateway.com
------------------
EWD Mobile: Build mobile applications faster
http://www.mgateway.com/ewd.html
Kingsley Idehen
> Hi Kingsley,
>
> I guess because I am ignorant of said Multi Model DBMSes. What other
> DB integrated a "GraphDB + RDBMS + KV Store + Document Store", I am
> genuinely interested.
>
> Also, having written this stuff, I know it's not rocket science, it's
> just pretty difficult, my original title was "The creation of a Data
> Platform" but I got feedback that that was too boring, so I went w/
> the more ooh-la-la title ... so perhaps it is just a reflection of our
> times :)
>
> - jak
Google up on OpenLink Virtuoso.
And if you want to see how its being used, you can do the same or look at:
1. http://dbpedia.org/About -- DBpedia
2. http://richard.cyganiak.de/2007/10/lod/ - LOD Cloud
3.
https://docs.google.com/spreadsheet/ccc?key=0AsEsF235XKNidHctRFdISkhZRXNHZVZWdmFwSGpHbVE#gid=0
-- for some benchmarks based on a 52 Billion+ dataset in Virtuoso .
If you wanna play ball, I am game. Ideally, you should start by making
some variant of the above since the data is publicly available.
Kingsley
Jak Sprats
so of course this type of technology has been possible for decades ...
I wrote it in C & Lua .. it is possible to argue that most software
has been possible for 40 years, we just arrange it differently.
I know about GT.M & Cache, and yeah, they can do most anything.
Perhaps I should have said, the first, w/ explicit bindings for
GraphDB's, and w/ Lua as a document store, and w/ redis' data
structure approach, etc... but it would have been a bad title.
what I will learn from this post here is to if you claim something as
the "first" people will focus in on that, instead of the meat of the
article.
- jak
On Mar 1, 9:23 am, Rob Tweed <rob.tw...@gmail.com> wrote:
> This kind of thing has been possible for decades with the right technology.
> See our paper dating from 2010:
>
> http://www.mgateway.com/docs/universalNoSQL.pdf
>
> Rob
>
Jak Sprats
so yeah, it looks like Openlink Virtuoso can do a whole lot of
Multimodel data-storage, like a whole lot :)
this list here is a very impressive feature list:
http://virtuoso.openlinksw.com/features-comparison-matrix/
I have not heard too much about Openlink Virtuoso, possibly because
most of the datastore information I get is about open source projects
(ah you guys have an open source version). This looks like a really
interesting piece of software though, as a techie I am insanely
interested in how you guys implemented everything, so I will read thru
your white papers (downloading http://docs.openlinksw.com/pdf/virtdocs.pdf
is taking a long time :).
Is Openlink Virtuoso aimed at OLTP or Analytics? Is it distributed
(horizontally) or single-node? Is it thread based, event driven? What
is its optimal use-case?
> If you wanna play ball, I am game. Ideally, you should start by making
> some variant of the above since the data is publicly available.
I would be happy to, let me explain what AlchemyDB is designed for, in
the spirit of having a relevant benchmark.
AlchemyDB is single-threaded, and 100% inRam. It is designed to give
low latency data-store responses for data that can be represented as
[SQL,DocumentStore,Graph,Redis]. AlchemyDB is designed for short-
running requests (i.e. no analytics). So it is a specialised tool for
a specialised use-case, using it for anything outside of use-cases
that match this pattern is a BAD idea :)
The raison-d'etre for AlchemyDB is I have needed a low latency data-
store that can do more than what a RDBMS could do, for many many
websites, that want to deliver a webpage (or snippet) back to the user
as quickly as possible to maximise use experience. So AlchemyDB can be
thought of as looking up data on another machine quickly w/ some
powerful data structure bindings thrown in.
So I am happy to benchmark against Open Virtuoso (if that is what play
ball means) but if the benchmark is for use-cases AlchemyDB was not
designed for, I would recommend not using AlchemyDB in the
benchmark :)
- jak
Kingsley Idehen
> Hi Kingsley,
>
> so yeah, it looks like Openlink Virtuoso can do a whole lot of
> Multimodel data-storage, like a whole lot :)
>
> this list here is a very impressive feature list:
> http://virtuoso.openlinksw.com/features-comparison-matrix/
>
> I have not heard too much about Openlink Virtuoso, possibly because
> most of the datastore information I get is about open source projects
> (ah you guys have an open source version). This looks like a really
> interesting piece of software though, as a techie I am insanely
> interested in how you guys implemented everything, so I will read thru
> your white papers (downloading http://docs.openlinksw.com/pdf/virtdocs.pdf
> is taking a long time :).
>
> Is Openlink Virtuoso aimed at OLTP or Analytics? Is it distributed
> (horizontally) or single-node? Is it thread based, event driven? What
> is its optimal use-case?
it the WWW, Enterprise, or both.
>
>> If you wanna play ball, I am game. Ideally, you should start by making
>> some variant of the above since the data is publicly available.
> I think this means, if I want to benchmark against Openlink Virtuoso,
> I would be happy to, let me explain what AlchemyDB is designed for, in
> the spirit of having a relevant benchmark.
>
> AlchemyDB is single-threaded, and 100% inRam.
Virtuoso is multi-threaded with the ability to make smart use of RAM be
it stand-along or across horizontal partitions re. "shared nothing"
clusters configs.
> It is designed to give
> low latency data-store responses for data that can be represented as
> [SQL,DocumentStore,Graph,Redis]. AlchemyDB is designed for short-
> running requests (i.e. no analytics). So it is a specialised tool for
> a specialised use-case, using it for anything outside of use-cases
> that match this pattern is a BAD idea :)
Yes, clearly.
Virtuoso is targeted at co-Relational and coSQL. It lets you exploit the
following DBMS dimensions:
1. Extensional -- what the old decision support or oltp RDBMS engines
offer under the SQL RDBMS banner
2. Intensional -- what the OODBMS tried to deliver modulo declarative
query language (and failed, OQL came to late) ; what OORDBMS tried to
deliver by extending SQL (but de-reference and data access was
implicitly product specific and ODBC/JDBC hooks didn't provide
alleviation for this issues)
3. Extensional and/or Intensional -- co-Relational and/or coSQL subject
to DBMS exploitation goals.
>
> The raison-d'etre for AlchemyDB is I have needed a low latency data-
> store that can do more than what a RDBMS could do, for many many
> websites, that want to deliver a webpage (or snippet) back to the user
> as quickly as possible to maximise use experience. So AlchemyDB can be
> thought of as looking up data on another machine quickly w/ some
> powerful data structure bindings thrown in.
>
> So I am happy to benchmark against Open Virtuoso (if that is what play
> ball means) but if the benchmark is for use-cases AlchemyDB was not
> designed for, I would recommend not using AlchemyDB in the
> benchmark :)
I think a benchmark between these products would be unfair :-)
Anyway, I have a clearer understanding of your product.
>
> - jak