On 7/07/09 22:39, Luke Kanies wrote: > On Jul 7, 2009, at 10:34 AM, Sam Rowe wrote: > >> On Tue, Jul 7, 2009 at 10:20 AM, James Turnbull<[email protected] >>> wrote: >>> Not being an expert on this and excuse me if this is a stupid >>> question >>> ... :) If this essentially replaced a back-end RDBMS - is it easy >>> for >>> people to query the data with other tools? For example, now I have >>> my >>> database of stored configuration I can readily query it via SQL - >>> how do >>> I get the same results with TC (can I?)? >> Also not being an expert, I'd suggest that it might actually be easier >> to query the data because the datastore matches the schema. > > Well, it's schemaless, isn't it?
Well, yes and no. There are different kind of back-end. One of them called Table is using a schema (the schema is not fixed in fact, it is free-form but supports columns and such) where you have to define a primary key, and it can index on any column. On top of that you have an API to modelize requests. I think I'll play with this during the week-end. What I want to check is how ACID the system is when multiple tables are bound in a transaction (and the API/doc doesn't seem to be clear on this). Also, I'd like to experiment with the various API, the provided ruby one looks really awful (kind of direct mapping of the C version I guess). But there seems to be another one, FFI based. > It's basically just a key/value store, and the data we're storing is > definitely not just key/value. If anything, a graph database is the > best model, but the only one that seems to be around is neo4j, and > we're not ready to depend on a java library. > > I'm not really sure how a catalog, much less hundreds or thousands of > them, plus node data, plus fact data, would map onto a key/value > store. Would each one be stored serialized as the value of a key like > 'catalog_<nodename>'? That's what I first thought, hence one of my previous message about namespaces and such. > So, I don't think it's trivially straightforward. And even if it > were, we still need to go through the process of turning our query > language into an abstract query system to go between the language > itself and the backend, just like AR is an abstract means of querying > sql. And I do agree that's the hard part. Hopefully you were pretty restrictive in what exported collector we support. >>> Secondly, how does it scale? Are there examples of large - and I >>> suspect someone on the list can fill in volumes statistics - hash >>> databases implemented in TC? We have some users who simply cannot >>> use >>> stored configuration because it kills their installations as a >>> result of >>> not scaling - Nigel at Google I am looking at you... :) >> According to the presentation slides here: >> http://tokyocabinet.sourceforge.net/ the answer is: very well. > > > I guess we would be fine here, given that the server version supports > all of the replication and stuff. Yes, that's an interesting property of the system. -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
