kai-users Mailing List for kai
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(31) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Takeru I. <tak...@gm...> - 2010-05-05 13:14:00
|
Hi Kshipra, Thank you for the interesting offer. I am a Kai developer, and very interested in writing a NoSQL book. I can offer sections about Kai or the Amazon's Dynamo technology, if the book describes several Open Source NoSQL databases. I have experience to write academic papers in English. You can find some of them in the following link. http://scholar.google.com/scholar?hl=en&q=author%3A%22takeru+inoue%22&btnG=Search&as_sdt=2000&as_ylo=&as_vis=0 http://teahut.sakura.ne.jp/t/inoue10rapid.pdf Regards, On Wed, May 5, 2010 at 9:01 PM, Kshipra Singh <ksh...@pa...> wrote: > Hi All, > > I am writing to you for Packt Publishing, the publishers of computer related > books. > > We are planning to expand the catalogue of our books on databases and are > looking forward to publish some books on NoSQL. > > Currently we are inviting people interested in writing NoSQL books for > Packt. This doesn't need any past writing experience. All that we need is an > expert subject knowledge, a passion to share it with others and an ability > to communicate clearly in English. > > So, if you love Kai or Amazon Dynamo and fancy writing a book, send your > book ideas to us at au...@pa.... Even if you don't have a book idea > and are simply interested in writing a book, we are still keen to hear from > you. > > More details about the opportunity are available at: > http://authors.packtpub.com/content/inviting-open-source-nosql-databases-fanatics-write-packt > > Thanks > Kshipra Singh > Author Relationship Manager > Packt Publishing > www.PacktPub.com > > Skype: kshiprasingh15 > Twitter: http://twitter.com/packtauthors > > Interested in becoming an author? Visit http://authors.packtpub.com for all > the information you need about writing for Packt. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Kai-users mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users > > -- Takeru INOUE |
From: Kshipra S. <ksh...@pa...> - 2010-05-05 12:39:21
|
Hi All, I am writing to you for Packt Publishing, the publishers of computer related books. We are planning to expand the catalogue of our books on databases and are looking forward to publish some books on NoSQL. Currently we are inviting people interested in writing NoSQL books for Packt. This doesn't need any past writing experience. All that we need is an expert subject knowledge, a passion to share it with others and an ability to communicate clearly in English. So, if you love Kai or Amazon Dynamo and fancy writing a book, send your book ideas to us at au...@pa.... Even if you don't have a book idea and are simply interested in writing a book, we are still keen to hear from you. More details about the opportunity are available at: http://authors.packtpub.com/content/inviting-open-source-nosql-databases-fanatics-write-packt Thanks Kshipra Singh Author Relationship Manager Packt Publishing www.PacktPub.com Skype: kshiprasingh15 Twitter: http://twitter.com/packtauthors Interested in becoming an author? Visit http://authors.packtpub.com for all the information you need about writing for Packt. |
From: Takeru I. <tak...@gm...> - 2009-05-21 14:41:04
|
Hi, We're very glad to let you know the new release of Kai. This release has great operational features including Cacti templates as well as stats and version of memcache API. Moreover, it is being deployed in "goo home", http://home.goo.ne.jp/, a Japanese social networking service of more than 10M accounts. This release will be the first production use of Kai. You can download it from https://sourceforge.net/project/showfiles.php?group_id=228337 . Our next work includes detailed documentation. It has about 5,000 words, and will be unveiled in this June. The operational features of 0.4.0 and this up-coming documents support your use of Kai. Regards, -- Takeru INOUE |
From: Takeru I. <tak...@gm...> - 2008-10-23 10:14:13
|
Hi, Matt Thank you for your interests. > Your Kai project looks very interesting. I was reading the Dynamo paper and > wanting to implement it, but found your project first. > > I was able to get it running out of SVN without any problems--always a good > sign! > > I'm wondering if there is a user forum or mailing list? I didn't find it on > sourceforge, but perhaps I missed it? We have two English mailing lists; kai...@li... is for users and kai...@li... is for developers. You can find them at https://sourceforge.net/mail/?group_id=228337 Unfortunately for you, past discussion was mostly made in Japanese lists, because most of developers are Japanese. Of course, English posts are welcome! > How active is development? I saw your roadmap--any idea how long it would > take to get to the full dynamo feature set? Are you currently using Kai > anywhere in "production"? We are going to release new versions every couple of months. Any deadline is, however, not set, since developers are working with this project as Sunday programmers. > Is the current SVN version useable? In that you would expect there would be > no data loss? (or are not currently aware of data-loss situations?) > > In the dynamo paper they mention various different plugable storage engines, > I think BDB and MySQL. What backend are you using? > > I want to run this on EC2, and would like to start one copy and then have > the data checkpointed to s3 at various intervals, so that at a complete > restart data loss would be minimal. Perhaps this is outside the scope of > the project. Which type of data loss are you assuming? Network failure and/or disk failure? I think that Kai can support your project If I can get your point. Theoretically, unless more than two nodes are getting down at the same time, no data loss will be found in Kai as well as Dynamo. Kai is, however, still in alpha stage, and you may encounter data losses because of bugs :-( In Kai, Erlang built-in storages are used; ets is memory storage and dets is disk-based one. Default is the memory storage, but the disk-based storage can be used as follows: % erl -pa ebin -config kai -kai store dets -kai dets_dir /path/to/dir where dets_dir is a directory in which storage files are. How to running Kai is described at the getting-started page http://kai.wiki.sourceforge.net/getting+started Kai with disk-based storage support is still under development and found at the following URL: http://kai.svn.sourceforge.net/svnroot/kai/branches/takemaru_store_dets/ Regards, -- Takeru INOUE <tak...@gm...> |
From: Justin S. <ju...@ba...> - 2008-09-15 15:35:52
|
Hello Davies, Thanks for your interest. The current implementation does not yet make any attempt at space optimization only due to the fact that the single application it is actively used in does not happen to need very large trees in practice at this time. I know of a few ways we could reduce the space used; they just haven't been worthwhile to focus on yet. Also, the internal structure used for the trees right off was somewhat space-wasteful due to focusing the first swing more on being relatively easy to understand. We're certainly interested in improving efficiency at some point - if you care about it now, I'd welcome either private discussion or patches in the interest of improvement. Best, -Justin On 9/15/08 11:07 AM, "Davies Liu" <dav...@gm...> wrote: I care about the Space-efficient of Merkle Tree, how many keys (with length 20 bytes) can been stored in 1G memory? Thank you. Best regards, Davies Liu On Mon, Sep 15, 2008 at 9:53 PM, Justin Sheehy <ju...@ba...> wrote: Hello All, (erlang-questions is on the CC list because there was interest in this topic before and I do not know of a general announcement list for such things) This is the second release of distributerl. The first had no version number, and was mainly intended to get the code into the hands of other potential users and experimenters as quickly as possible -- motivated by requests for such code by projects including but not limited to the Kai project. The distributerl-0.1 release is driven by two improvements to the Merkle Tree module: 1. User-specified keys for objects are now arbitrary terms instead of being restricted to 160b binaries. 2. A bug that caused incorrect diff/2 results has been fixed. Due to item #2, any systems making use of merkerl.erl should upgrade. A couple of smaller handy features were also added: 1. New function merkerl:delete/2 means that items can be deleted from trees. 2. New function merkerl:allkeys/1 will return the keys for all objects in a tree. (The vclock and chash modules are unchanged in this release) Future releases will include generic versioned objects, gossip protocol, and proper packaging of the modules. The project can be found at http://code.google.com/p/distributerl/ If you have any thoughts or questions about this, just drop me a line. Cheers, -Justin _______________________________________________ erlang-questions mailing list erl...@er... http://www.erlang.org/mailman/listinfo/erlang-questions |
From: Davies L. <dav...@gm...> - 2008-09-15 15:07:53
|
I care about the Space-efficient of Merkle Tree, how many keys (with length 20 bytes) can been stored in 1G memory? Thank you. Best regards, Davies Liu On Mon, Sep 15, 2008 at 9:53 PM, Justin Sheehy <ju...@ba...> wrote: > Hello All, > > (erlang-questions is on the CC list because there was interest in this > topic > before and I do not know of a general announcement list for such things) > > This is the second release of distributerl. The first had no version > number, > and was mainly intended to get the code into the hands of other potential > users and experimenters as quickly as possible -- motivated by requests for > such code by projects including but not limited to the Kai project. The > distributerl-0.1 release is driven by two improvements to the Merkle Tree > module: > > 1. User-specified keys for objects are now arbitrary terms > instead of being restricted to 160b binaries. > 2. A bug that caused incorrect diff/2 results has been fixed. > > Due to item #2, any systems making use of merkerl.erl should upgrade. > > A couple of smaller handy features were also added: > > 1. New function merkerl:delete/2 means that items can be > deleted from trees. > 2. New function merkerl:allkeys/1 will return the keys for > all objects in a tree. > > (The vclock and chash modules are unchanged in this release) > > Future releases will include generic versioned objects, gossip protocol, > and > proper packaging of the modules. > > The project can be found at http://code.google.com/p/distributerl/ > > If you have any thoughts or questions about this, just drop me a line. > > Cheers, > > -Justin > > > _______________________________________________ > erlang-questions mailing list > erl...@er... > http://www.erlang.org/mailman/listinfo/erlang-questions > |
From: Justin S. <ju...@ba...> - 2008-09-15 13:53:52
|
Hello All, (erlang-questions is on the CC list because there was interest in this topic before and I do not know of a general announcement list for such things) This is the second release of distributerl. The first had no version number, and was mainly intended to get the code into the hands of other potential users and experimenters as quickly as possible -- motivated by requests for such code by projects including but not limited to the Kai project. The distributerl-0.1 release is driven by two improvements to the Merkle Tree module: 1. User-specified keys for objects are now arbitrary terms instead of being restricted to 160b binaries. 2. A bug that caused incorrect diff/2 results has been fixed. Due to item #2, any systems making use of merkerl.erl should upgrade. A couple of smaller handy features were also added: 1. New function merkerl:delete/2 means that items can be deleted from trees. 2. New function merkerl:allkeys/1 will return the keys for all objects in a tree. (The vclock and chash modules are unchanged in this release) Future releases will include generic versioned objects, gossip protocol, and proper packaging of the modules. The project can be found at http://code.google.com/p/distributerl/ If you have any thoughts or questions about this, just drop me a line. Cheers, -Justin |
From: Takeru I. <tak...@gm...> - 2008-07-31 00:32:52
|
Good job! The three algorithms are essential in most of distributed data store. Especially, merkle.erl enables the tree to grow incrementally. This is great feature. On Thu, Jul 31, 2008 at 5:22 AM, Justin Sheehy <ju...@ba...> wrote: >> On 7/14/08 10:09 AM, "Takeru INOUE" <tak...@gm...> wrote: >> >>>>> What good news! >>>>> We were seeking vector clocks and Merkle tree. > > Several people have been asking about this for a while, so I decided > to just go ahead and put it online. The google code project at > http://code.google.com/p/distributerl/ now has vector clocks, > consistent hashing, and a Merkle tree implementation that is suitable > for dynamic trees. > > The Merkle trees are somewhat different from the traditional style of > construction algorithm, because the common way to do it works very > well for the original use (digital signatures) but does not adapt > easily to trees representing data that changes incrementally over time. > > The documentation is minimal but functional right now. If anyone has > questions about this, feel free to either ask me or post to the google > group tied to the code repository. > > Enjoy. > > -Justin > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Kai-users mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users > -- Takeru INOUE <tak...@gm...> |
From: Justin S. <ju...@ba...> - 2008-07-30 20:22:19
|
> On 7/14/08 10:09 AM, "Takeru INOUE" <tak...@gm...> wrote: > >>>> What good news! >>>> We were seeking vector clocks and Merkle tree. Several people have been asking about this for a while, so I decided to just go ahead and put it online. The google code project at http://code.google.com/p/distributerl/ now has vector clocks, consistent hashing, and a Merkle tree implementation that is suitable for dynamic trees. The Merkle trees are somewhat different from the traditional style of construction algorithm, because the common way to do it works very well for the original use (digital signatures) but does not adapt easily to trees representing data that changes incrementally over time. The documentation is minimal but functional right now. If anyone has questions about this, feel free to either ask me or post to the google group tied to the code repository. Enjoy. -Justin |
From: Takeru I. <tak...@gm...> - 2008-07-16 12:02:26
|
Thank you so much. I tried vclock.erl and found it works correctly. We will build it into our code. We're preparing some useful codes. I'll post it to this list when it's done. On Wed, Jul 16, 2008 at 9:12 AM, Justin Sheehy <ju...@ba...> wrote: > On 7/14/08 10:09 AM, "Takeru INOUE" <tak...@gm...> wrote: > >>>> What good news! >>>> We were seeking vector clocks and Merkle tree. >>> >>> I'll certainly let you know as soon as I have prepared a release, which >>> should not take much work. The code already exists, it is just a matter of >>> packaging and licensing. >> >> Thanks a lot. >> We're looking forward to hearing good news. > > Here is the first part of your good news. > > I have put up the vector clocks module here: > > http://code.google.com/p/vclock/ > > Vector clocks become much more useful once you also have Merkle trees. I > will package up and release an implementation of those soon as well. > > However, since vector clocks can be useful on their own and I was able to > get this part out more quickly, I thought I'd give you something incremental > to look at. It is not a large amount of code, but we have found it quite > handy. > > Best, > > -Justin > > > -- Takeru INOUE <tak...@gm...> |
From: Justin S. <ju...@ba...> - 2008-07-16 00:12:22
|
On 7/14/08 10:09 AM, "Takeru INOUE" <tak...@gm...> wrote: >>> What good news! >>> We were seeking vector clocks and Merkle tree. >> >> I'll certainly let you know as soon as I have prepared a release, which >> should not take much work. The code already exists, it is just a matter of >> packaging and licensing. > > Thanks a lot. > We're looking forward to hearing good news. Here is the first part of your good news. I have put up the vector clocks module here: http://code.google.com/p/vclock/ Vector clocks become much more useful once you also have Merkle trees. I will package up and release an implementation of those soon as well. However, since vector clocks can be useful on their own and I was able to get this part out more quickly, I thought I'd give you something incremental to look at. It is not a large amount of code, but we have found it quite handy. Best, -Justin |
From: Takeru I. <tak...@gm...> - 2008-07-14 14:09:23
|
>> What good news! >> We were seeking vector clocks and Merkle tree. > > I'll certainly let you know as soon as I have prepared a release, which > should not take much work. The code already exists, it is just a matter of > packaging and licensing. Thanks a lot. We're looking forward to hearing good news. >> But I don't know whether it is better to merge two projects, because >> current goals of the projects are a little bit different and systems >> will be complicated if merging. >> This is not as negative criticism, but I think that it is hard to >> merge the projects until both projects are getting stable (at least >> Kai is not stable :). > > Of course. On that topic I was partially responding agreeably to Jan's idea > and partially speculating about the future. > >> I'd like to discuss elemental technologies, such as >> reliability and vector clocks > > I'm happy to discuss these any time. I have now joined the kai mailing > lists -- but only the English versions. It looks like most of the > conversation happens on the -jp lists, which I am sadly unable to read. This is because all developers are Japanese. I guess that most of discussions are in Japanese in the meantime, but I'll translate and forward it to English lists when big news come. > -Justin > > > -- Takeru INOUE <tak...@gm...> |
From: Takeru I. <tak...@gm...> - 2008-07-14 14:08:42
|
>> In the current implementation, parameters like R and W are configured >> per node basis. >> However, these parameters must be shared in the whole system. >> It's better to exchange the parameters before joining the system. > > Actually, no. I meant somewhat the opposite. > > You want N to be shared across the system, but to be able to specify R or W > on a per-request basis from each client. This way you can leave some of the > CAP balancing to the specific application use. I had no idea to specify R or W per a request and there seems to be technical difficulties, but is attractive for some application. I'll add it to our TODO list. Thanks. > -Justin > > > -- Takeru INOUE <tak...@gm...> |
From: Justin S. <ju...@ba...> - 2008-07-13 17:34:09
|
On 7/13/08 12:13 PM, "Takeru INOUE" <tak...@gm...> wrote: > What good news! > We were seeking vector clocks and Merkle tree. I'll certainly let you know as soon as I have prepared a release, which should not take much work. The code already exists, it is just a matter of packaging and licensing. > But I don't know whether it is better to merge two projects, because > current goals of the projects are a little bit different and systems > will be complicated if merging. > This is not as negative criticism, but I think that it is hard to > merge the projects until both projects are getting stable (at least > Kai is not stable :). Of course. On that topic I was partially responding agreeably to Jan's idea and partially speculating about the future. > I'd like to discuss elemental technologies, such as > reliability and vector clocks I'm happy to discuss these any time. I have now joined the kai mailing lists -- but only the English versions. It looks like most of the conversation happens on the -jp lists, which I am sadly unable to read. -Justin |
From: Justin S. <ju...@ba...> - 2008-07-13 17:31:20
|
On 7/13/08 12:14 PM, "Takeru INOUE" <tak...@gm...> wrote: >> Also, to get real value out of your R and W parameters you will need to move >> away from setting them globally for a whole cluster and instead make them >> per-request parameters. > > Good point. > In the current implementation, parameters like R and W are configured > per node basis. > However, these parameters must be shared in the whole system. > It's better to exchange the parameters before joining the system. Actually, no. I meant somewhat the opposite. You want N to be shared across the system, but to be able to specify R or W on a per-request basis from each client. This way you can leave some of the CAP balancing to the specific application use. -Justin |
From: Takeru I. <tak...@gm...> - 2008-07-13 16:15:50
|
As I mentioned in the reply to Justin, I'd like to discuss element technology such as reliability and vector clocks. I subscribed CouchDB developer list :-) On Sun, Jul 13, 2008 at 10:48 PM, Jan Lehnardt <ja...@ap...> wrote: > CouchDB is getting well known in Japan, especially its sophisticated > RESTful interface. > This is because Yohei, who supervised a translation of "RESTful Web > Services", is intrigued with CouchDB. > > Wow, this is cool :) Thanks for the info. > > Is the interest in merging our systems mutual? > > This is interesting suggestion. > We're now focusing on reliability and scalability, and keeping its > interface simple; get(key) and put(key, value). > But more complicated queries like CouchDB can be our future work, and > it seems exciting. > > With CouchDB we have such an easy interface, so connecting should > be trivial: > GET /database/key == get(key) > PUT /database/key > value (in the PUT request body) == put(key, value) > CouchDB also has more API calls for querying and all that, > but that could be independent of the fault tolerance layer > you provide. At least at first, to make things easier. > > Of course, you can merge our code into CouchDB freely, since Kai is > based on Apache License 2.0. > > We are not very keen on just taking some code that we'd then have > to maintain ourselves (or we are just lazy :). The truth is though, that > a database system is enough work in itself and if we could make our > systems interoperable both our teams would benefit and have less > work to do. > It'd be great if we can work together. I'll forward this mail to the > CouchDB developer list and will keep an eye on the Kai lists as > well. > Cheers > Jan > -- > > If there anything is you would like to know, do > > not hesitate to contact me (here or in private if > > preferred). > > Keep up the good work! > > Cheers > > Jan > > -- > > > Kai is a distributed hashtable like Amazon's Dynamo. > > Dynamo is described in its original paper, as a highly available > > key-value storage system that some of Amazon's core services use to > > provide an "always-on" experience. > > Kai implements well-known memcache API, and you can access to Kai with > > your favorite programming language. > > Kai is hosted on sourceforge.net, where detailed information is found. > > http://kai.wiki.sourceforge.net/ > > Also, source code can be downloaded. > > http://sourceforge.net/project/showfiles.php?group_id=228337 > > If you are interested in Kai, read Getting Started and try it. > > http://kai.wiki.sourceforge.net/getting+started > > Regards, > > -- > > Takeru INOUE <tak...@gm...> > > _______________________________________________ > > erlang-questions mailing list > > erl...@er... > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > > > > -- > Takeru INOUE <tak...@gm...> > > > -- Takeru INOUE <tak...@gm...> |
From: Takeru I. <tak...@gm...> - 2008-07-13 16:14:22
|
> If you are to begin to have some of the same features as Dynamo such as > write-availability via object versioning, the interface will have to get a > little bit richer to indicate ancestor objects in put requests. Yes. To represent some version information, Kai will support 'cas' of memcache API. With 'cas', a kind of version can be put in the request and response. This realizes optimistic lock. > Also, to get real value out of your R and W parameters you will need to move > away from setting them globally for a whole cluster and instead make them > per-request parameters. Good point. In the current implementation, parameters like R and W are configured per node basis. However, these parameters must be shared in the whole system. It's better to exchange the parameters before joining the system. > This is intended not as negative criticism of Kai but rather as pointers to > some future changes you are likely to need in any case which will force you > to think more about the client interface. > > Best, > > -Justin > > > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Kai-users mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users > -- Takeru INOUE <tak...@gm...> |
From: Takeru I. <tak...@gm...> - 2008-07-13 16:13:47
|
>>> Is the interest in merging our systems mutual? > >> This is interesting suggestion. >> We're now focusing on reliability and scalability, and keeping its >> interface simple; get(key) and put(key, value). >> But more complicated queries like CouchDB can be our future work, and >> it seems exciting. > > I am also very interested in this suggestion, and can offer some help. > > When my team was beginning its current (not yet released) work, CouchDB was > just seeing the light of day. I was intrigued, and discussed it with Damien > as he was the sole developer at the time. I decided that while it was very > interesting and I'd keep my eye on it, our operational needs for redundancy, > scalability, and availability were not going to be high priorities in > CouchDB anytime soon. As a result, we rolled our own internal solution to > our storage problems. > > We are prepared to contribute some of the core missing pieces of Kai, which > might cause this merge to happen sooner. For instance, we have working > Erlang/OTP implementations of Lamport vector clocks, Merkle trees, and more. > We are happy to provide these under the Apache License 2.0; it will just > take a little bit of packaging as they have not been given away before. What good news! We were seeking vector clocks and Merkle tree. > Over time, we would be happy to provide more contributions, as it would be > very nice for a superset of our business needs to be supplied by an open > source project we could use. > > We'll make some of the aforementioned code available soon in any case. If > there is a real desire by the two projects to discuss merging sometime soon, > we could also help with some of the needs that I am certain such a merger > will have. Thank you for the suggestion. But I don't know whether it is better to merge two projects, because current goals of the projects are a little bit different and systems will be complicated if merging. This is not as negative criticism, but I think that it is hard to merge the projects until both projects are getting stable (at least Kai is not stable :). Of course, I'd like to discuss elemental technologies, such as reliability and vector clocks. > -Justin > > > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Kai-users mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users > -- Takeru INOUE <tak...@gm...> |
From: Jan L. <ja...@ap...> - 2008-07-13 13:48:26
|
> CouchDB is getting well known in Japan, especially its sophisticated > RESTful interface. > This is because Yohei, who supervised a translation of "RESTful Web > Services", is intrigued with CouchDB. Wow, this is cool :) Thanks for the info. >> Is the interest in merging our systems mutual? > > This is interesting suggestion. > We're now focusing on reliability and scalability, and keeping its > interface simple; get(key) and put(key, value). > But more complicated queries like CouchDB can be our future work, and > it seems exciting. With CouchDB we have such an easy interface, so connecting should be trivial: GET /database/key == get(key) PUT /database/key value (in the PUT request body) == put(key, value) CouchDB also has more API calls for querying and all that, but that could be independent of the fault tolerance layer you provide. At least at first, to make things easier. > Of course, you can merge our code into CouchDB freely, since Kai is > based on Apache License 2.0. We are not very keen on just taking some code that we'd then have to maintain ourselves (or we are just lazy :). The truth is though, that a database system is enough work in itself and if we could make our systems interoperable both our teams would benefit and have less work to do. It'd be great if we can work together. I'll forward this mail to the CouchDB developer list and will keep an eye on the Kai lists as well. Cheers Jan -- >> If there anything is you would like to know, do >> not hesitate to contact me (here or in private if >> preferred). >> >> Keep up the good work! >> >> Cheers >> Jan >> -- >> >> >>> Kai is a distributed hashtable like Amazon's Dynamo. >>> Dynamo is described in its original paper, as a highly available >>> key-value storage system that some of Amazon's core services use to >>> provide an "always-on" experience. >>> Kai implements well-known memcache API, and you can access to Kai >>> with >>> your favorite programming language. >>> >>> Kai is hosted on sourceforge.net, where detailed information is >>> found. >>> >>> http://kai.wiki.sourceforge.net/ >>> >>> Also, source code can be downloaded. >>> >>> http://sourceforge.net/project/showfiles.php?group_id=228337 >>> >>> If you are interested in Kai, read Getting Started and try it. >>> >>> http://kai.wiki.sourceforge.net/getting+started >>> >>> Regards, >>> >>> -- >>> Takeru INOUE <tak...@gm...> >>> _______________________________________________ >>> erlang-questions mailing list >>> erl...@er... >>> http://www.erlang.org/mailman/listinfo/erlang-questions >>> >> >> > > > > -- > Takeru INOUE <tak...@gm...> > |
From: Justin S. <ju...@ba...> - 2008-07-13 11:07:41
|
On Jul 12, 2008, at 10:50 PM, Takeru INOUE wrote: > We're now focusing on reliability and scalability, and keeping its > interface simple; get(key) and put(key, value). > But more complicated queries like CouchDB can be our future work, and > it seems exciting. If you are to begin to have some of the same features as Dynamo such as write-availability via object versioning, the interface will have to get a little bit richer to indicate ancestor objects in put requests. Also, to get real value out of your R and W parameters you will need to move away from setting them globally for a whole cluster and instead make them per-request parameters. This is intended not as negative criticism of Kai but rather as pointers to some future changes you are likely to need in any case which will force you to think more about the client interface. Best, -Justin |
From: Justin S. <ju...@ba...> - 2008-07-13 11:01:46
|
On Jul 12, 2008, at 10:50 PM, Takeru INOUE wrote: >> Is the interest in merging our systems mutual? > This is interesting suggestion. > We're now focusing on reliability and scalability, and keeping its > interface simple; get(key) and put(key, value). > But more complicated queries like CouchDB can be our future work, and > it seems exciting. I am also very interested in this suggestion, and can offer some help. When my team was beginning its current (not yet released) work, CouchDB was just seeing the light of day. I was intrigued, and discussed it with Damien as he was the sole developer at the time. I decided that while it was very interesting and I'd keep my eye on it, our operational needs for redundancy, scalability, and availability were not going to be high priorities in CouchDB anytime soon. As a result, we rolled our own internal solution to our storage problems. We are prepared to contribute some of the core missing pieces of Kai, which might cause this merge to happen sooner. For instance, we have working Erlang/OTP implementations of Lamport vector clocks, Merkle trees, and more. We are happy to provide these under the Apache License 2.0; it will just take a little bit of packaging as they have not been given away before. Over time, we would be happy to provide more contributions, as it would be very nice for a superset of our business needs to be supplied by an open source project we could use. We'll make some of the aforementioned code available soon in any case. If there is a real desire by the two projects to discuss merging sometime soon, we could also help with some of the needs that I am certain such a merger will have. -Justin |
From: Takeru I. <tak...@gm...> - 2008-07-13 02:49:52
|
> We are extremely interested in these kind of systems. > We, that are the CouchDB developers, sort of tackle > the same problem space, only from the other direction. > > Where Kai and Alexander Reinefeld (& co)'s work focus > on the distribution & fault tolerance, CouchDB aims to be > an attractive data store first. It is meant as an alternative > to the often wrongly (as in wrong tool for the job) used > RDBMSes. So CouchDB can be used standalone but > we are planning to have a fault tolerance layer on top > of CouchDB that deals with disappearing nodes and > all that. It would be really really cool if we could > collaborate on this. > > CouchDB comes with an HTTP interface, so is > accessible equally easy from all languages, > including Erlang, but it is not tied to Erlang. Since > such high availability systems are attractive for > homogenous environments, a well-known API > is a good idea and you certainly made a good > choice with the memcache API. CouchDB is getting well known in Japan, especially its sophisticated RESTful interface. This is because Yohei, who supervised a translation of "RESTful Web Services", is intrigued with CouchDB. > Is the interest in merging our systems mutual? This is interesting suggestion. We're now focusing on reliability and scalability, and keeping its interface simple; get(key) and put(key, value). But more complicated queries like CouchDB can be our future work, and it seems exciting. Of course, you can merge our code into CouchDB freely, since Kai is based on Apache License 2.0. > If there anything is you would like to know, do > not hesitate to contact me (here or in private if > preferred). > > Keep up the good work! > > Cheers > Jan > -- > > >> Kai is a distributed hashtable like Amazon's Dynamo. >> Dynamo is described in its original paper, as a highly available >> key-value storage system that some of Amazon's core services use to >> provide an "always-on" experience. >> Kai implements well-known memcache API, and you can access to Kai with >> your favorite programming language. >> >> Kai is hosted on sourceforge.net, where detailed information is found. >> >> http://kai.wiki.sourceforge.net/ >> >> Also, source code can be downloaded. >> >> http://sourceforge.net/project/showfiles.php?group_id=228337 >> >> If you are interested in Kai, read Getting Started and try it. >> >> http://kai.wiki.sourceforge.net/getting+started >> >> Regards, >> >> -- >> Takeru INOUE <tak...@gm...> >> _______________________________________________ >> erlang-questions mailing list >> erl...@er... >> http://www.erlang.org/mailman/listinfo/erlang-questions >> > > -- Takeru INOUE <tak...@gm...> |
From: Takeru I. <tak...@gm...> - 2008-07-13 02:48:14
|
>> Kai is still in the early stage, and we're now struggling with many >> issues. >> Sorry for the inconvenience. > > I didn't mean my comment as negative criticism of Kai, but rather just a > suggestion for a workaround. It's a nice first release -- there's no > need for any > apology. In fact, I may help you out with some of those issues > sometime soon. Oh, great! Thanks, we're expecting any help. > -Justin > > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Kai-users mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users > -- Takeru INOUE <tak...@gm...> |
From: Jan L. <ja...@ap...> - 2008-07-12 20:26:55
|
Hello, On Jul 11, 2008, at 15:29 , Takeru INOUE wrote: > I'd like to tell you about a project called Kai. We are extremely interested in these kind of systems. We, that are the CouchDB developers, sort of tackle the same problem space, only from the other direction. Where Kai and Alexander Reinefeld (& co)'s work focus on the distribution & fault tolerance, CouchDB aims to be an attractive data store first. It is meant as an alternative to the often wrongly (as in wrong tool for the job) used RDBMSes. So CouchDB can be used standalone but we are planning to have a fault tolerance layer on top of CouchDB that deals with disappearing nodes and all that. It would be really really cool if we could collaborate on this. CouchDB comes with an HTTP interface, so is accessible equally easy from all languages, including Erlang, but it is not tied to Erlang. Since such high availability systems are attractive for homogenous environments, a well-known API is a good idea and you certainly made a good choice with the memcache API. Is the interest in merging our systems mutual? If there anything is you would like to know, do not hesitate to contact me (here or in private if preferred). Keep up the good work! Cheers Jan -- > Kai is a distributed hashtable like Amazon's Dynamo. > Dynamo is described in its original paper, as a highly available > key-value storage system that some of Amazon's core services use to > provide an "always-on" experience. > Kai implements well-known memcache API, and you can access to Kai with > your favorite programming language. > > Kai is hosted on sourceforge.net, where detailed information is found. > > http://kai.wiki.sourceforge.net/ > > Also, source code can be downloaded. > > http://sourceforge.net/project/showfiles.php?group_id=228337 > > If you are interested in Kai, read Getting Started and try it. > > http://kai.wiki.sourceforge.net/getting+started > > Regards, > > -- > Takeru INOUE <tak...@gm...> > _______________________________________________ > erlang-questions mailing list > erl...@er... > http://www.erlang.org/mailman/listinfo/erlang-questions > |
From: Justin S. <ju...@ia...> - 2008-07-12 17:29:44
|
On Jul 12, 2008, at 1:23 PM, Takeru INOUE wrote: > Kai is still in the early stage, and we're now struggling with many > issues. > Sorry for the inconvenience. I didn't mean my comment as negative criticism of Kai, but rather just a suggestion for a workaround. It's a nice first release -- there's no need for any apology. In fact, I may help you out with some of those issues sometime soon. -Justin |