Ayende @ Rahien

Nick P commented on Embracing RavenDB

Mon, 12 Mar 2012 01:55:26 GMT

You actually made good arguments for an entirely different type of database: Object-oriented databases. I regularly see people wanting a database to just reliably store and retrieve data in their program, which takes the form of primitive types and objects. The ORM schemes are horrible. That they take a 5in thick book to teach is telling. A top-notch OODBMS like AllegroCache makes things so easy, conceptually & practically. (I named them b/c they were the best last time I looked into these things.) AllegroCache had the benefit of coming with the Allegro CL platform, which is incredibly powerful/flexible. I could see the same ease of use in a mainstream language with some tools that auto-generate boilerplate to operate with OODBMS. Your thoughts? I'll be resurveying those OODBMS's and taking a look at your RavenDB tonight.

Logan commented on Embracing RavenDB

Mon, 06 Feb 2012 15:16:44 GMT

"2 songs or 3 pictures"? That's an absurd frame of reference considering the only reason we have media files this large nowadays is because we have the cheap storage to keep them. No one would have thought to store a 3 megabyte image file on a hard disk back then. The way you word it makes it seem like that's legitimately what people were using them for. How about how many text files it could hold. Probably quite a few.

Paul Kelly commented on Embracing RavenDB

Mon, 06 Feb 2012 14:01:00 GMT

I feel compelled to nitpick. In the 80s, the typical application had hundreds or possibly thousands of users. And it ran on an IBM mainframe, or something that looked like one. And it was phenomenally efficient in the use of (as you pointed out) scarce and very expensive resources.

Simon Hibbard commented on Embracing RavenDB

Thu, 02 Feb 2012 17:50:32 GMT

Ayende, I appreciate you taking time to comment and take your points on board, I can see from the mailing list you have covered it all quite extensively. I was just sharing my own personal opinion and if I am one of the target market I presume this should count. We do get away with SQL Express or MySQL a lot of the time, which costs nothing. I know the cost here is relatively small but as I said many are looking to reduce and not add monthly overheads. Still it seems a very nice product and I have received only positive responses so far, so I was maybe a bit hasty to disregard it as an option.

Ayende Rahien commented on Embracing RavenDB

Thu, 02 Feb 2012 17:33:39 GMT

Simon, Compare the pricing for just about anything else, and you'll find that we are _extremely_ competitive. You might also want to check the pricing discussion in the mailing list here: http://groups.google.com/group/ravendb/browse_thread/thread/7aa34f35e49d01ab And it is very easy to say "monetize it later" when you aren't the one actually paying for the development and work on the product.

Eric commented on Embracing RavenDB

Thu, 02 Feb 2012 16:13:49 GMT

@DanielLang out of curiousity, what were the factors which made you decide that a document database was not suitable for a time tracking application?

Simon Hibbard commented on Embracing RavenDB

Thu, 02 Feb 2012 15:56:01 GMT

I know lots of developers, many feeling the squeeze right now and looking to cut costs not increase them and the cost is still per instance, per month (which adds up). Convincing people to move from a deeply entrenched tech is going to be hard enough as it it is, and the existing use of relational databases still works very well, it isn't actually broken. I can see the benefits nosql would bring (and RavenDB seems good to go for commercial work) but the combination of cost and learning curve to experiment is going to put many off. You may not agree, but I am one of those people, I read open-source and thought "right lets give this a go on my next project", then saw I have to sign up to a monthly plan and that combined with the effort to change tech was enough to put me off. If you want to truly get the masses on board, in my opinion, get the user base first, monetize it later.

Ayende Rahien commented on Embracing RavenDB

Thu, 02 Feb 2012 15:36:10 GMT

Simon, It costs 25$ a month. What do you expect? How much _lower_ do you think it can be? I am sorry, but even right now, I think that ravendb is priced far lower than it is worth. This is intentional, because we want to get as many users as possible.

Simon Hibbard commented on Embracing RavenDB

Thu, 02 Feb 2012 15:32:40 GMT

I looked at RavenDB and would have liked to start a few projects working with it, but as with many developers like myself it would be on a commercial project not just in my 'spare time'. But unfortunately the pricing is just too high to justify 'experimenting' with this new technology. To me the pricing model is alienating a huge amount of potential early adopters of technology and is a short sighted approach to getting what seems to be a great product the sort of user base that would bring it to the fore.

Ayende Rahien commented on Embracing RavenDB

Thu, 02 Feb 2012 10:13:51 GMT

Alex, Designing things based on the actual interaction? (And usually the UI follows those interactions.) Yes, that would be a way of starting out, and you can modify things along the way when you discover new stuff.

Fitzchak Yitzchaki commented on Embracing RavenDB

Thu, 02 Feb 2012 09:58:31 GMT

@peter, a pull request will be great. https://github.com/fitzchak/RaccoonBlog

Alex commented on Embracing RavenDB

Thu, 02 Feb 2012 09:53:57 GMT

Ayende, as a learning method for newbies, do you think modelling the documents after screen mockups (imagine they are well-defined transactions) is a good way to go?

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:33:37 GMT

Matthew, I don't think that NoSQL punishes you for bad data models faster. Well, maybe, for the general case. With RavenDB, you have enough freedom to do a LOT of querying options. Some things might not be optimal, and often we recommend different ways of modeling, but you _can_ make those queires.

Matthew Shapiro commented on Embracing RavenDB

Wed, 01 Feb 2012 23:23:49 GMT

@ayende, sorry I wasn't trying to say that starting from a data model is good, my point was that nosql databases punish you for that much faster for it. I would say that a lot if devs design apps data first (I'd also say most are inexperienced creating large enterprise level apps it just bad), and because of that they hit the wall quicker that tells them they are doing things badly.

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:21:47 GMT

Micha, RavenDB contains explicit code to avoid the too many requests issue. Badly performing indexes are actually quite rare. In 2.5 years I have seen exactly one case where the way that the index was defined was actually causing a performance problem, and that was a highly degenerate case. We usually recommend things on the basis of performance, but it is a ms difference during indexing more than anything else. You can look at the public apps we have for RavenDB (this blog being the major one), there are a few indexes that we defined by hand, the rest are auto indexes defined by RavenDB. For the most part, the indexes defined by hand are for specific purposes, and are quite easy to work with. Certainly more easy than the common "how do I make this page efficient" that I see pretty much everywhere with relational databases.

njy commented on Embracing RavenDB

Wed, 01 Feb 2012 23:18:41 GMT

@Oren: thanks for the doc link, since it is in the old site i wasn't able find that. About the average posting stat: yeah that was just a number to give an idea, plus i was remembering when people insinuated in real life you were a robot because of the high frequency of posts... so i may have exaggerated a bit :)

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:15:14 GMT

Micha, a) Most NoSQL solutions require very little maintenance. With RavenDB, the most common regular maintenance is running backups. You can schedule that easily enough with external tools. No need for RavenDB to implement a scheduled backup process when it is already exists. b) Most NoSQL solutions assume multiple nodes running at the same time. Usually a lot of them. You go ahead and try to run some task on all nodes manually. You _want_ to do that in a script. c) RavenDB comes with an awesome management tool

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:12:16 GMT

Vidar, Not really, no. Graph queries for RavenDB were added in a branch, but I decided that this is something that we want the community to do, not to do it ourselves. We want to focus on making RavenDB the best document database, not something that can do all things, but non too well.

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:11:11 GMT

Dan, You can do reporting on top of a non relational database, yes. But for the most part, you want a dedicate reporting database, what that is (SQL or not) is an implementation decision that should be answered based on the data size, update frequency and the types of reports needed.

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:10:00 GMT

Matthew, I would strongly disagree with that statement. In practically any application that I have seen, starting from the data model and then building the app was a mistake. It cements decisions that are made without actual understanding of the business scenarios and the needs of the application.

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:08:33 GMT

David, While I agree it would be interesting, I would like to get real world scenarios from other people, rather than have to make up stuff. That also make it more interesting because I don't tailor the scenario to RavenDB capabilities.

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:07:10 GMT

Njy, Also, the average over the last year or so have been 1 blog post per day, more or less

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:06:32 GMT

Njy, I believe we have made it clear on the RavenDB site. Take a look here: http://ravendb.net/documentation/docs-document-design

Ayende Rahien commented on Embracing RavenDB

Wed, 01 Feb 2012 23:05:20 GMT

Philip, session.Query() .Where(q=>q.CustomerId == "customers/1234") .ToList();

njy commented on Embracing RavenDB

Wed, 01 Feb 2012 23:04:22 GMT

@Daniel Lang: thanks, your blog seems *very* interesting, and filled up with *real world* use cases. Definitely count me in as a new feed subscriber ;-)

Daniel Lang commented on Embracing RavenDB

Wed, 01 Feb 2012 22:22:07 GMT

@njy: Yes - there are many such things you wouldn't otherwise deal with when using a traditional sql solution. If you're interested, take a look here: http://daniellang.net/tag/ravendb/ This is what I consider to be the result of a really hard and steep learning curve. And there _are_ pain points. For me, the hardest are migrations, lack of proper tool to inspect indexes, and ad-hoc querying. The last one can make you feel really sick, because there isn't even a good workaround except replicating an index out to sql-server, which I don't consider to be a workaround. I personally don't like to feel sick. So what do we do if we run across a situation where we have the need for massive ad-hoc querying (e.g. reporting)? The answer is - I use SQL Server then. The whole point of this NoSQL movement is to choose the right tools for the rights answers. At the moment, we're build a time-tracking system. This is something I wouldn't do in RavenDB. NHibernate is a perfect match here. I just find that RavenDB is the right tool for most of our application, but definitely not for all.

njy commented on Embracing RavenDB

Wed, 01 Feb 2012 21:58:17 GMT

@Daniel Lang: thanks for your sharing. Since you seem to have enough experience *on the field* I have a curiosity, if i may ask: are there any "fine tuning" phases (like creating some indexes in an rdbms) using ravendb, or you just (well... "just"...) need to work on the indexex definition, tuning the map/reduce part? Thanks.

Daniel Lang commented on Embracing RavenDB

Wed, 01 Feb 2012 21:46:09 GMT

It is clear that this comment will be a positive one, because I'm using RavenDB a _lot_. Not just for 'playing around' but for software projects that hopefully make me (and my collegues) smile at the end of the month. Now, let's google for "ravendb awesome". This will get you a ton of blogs an tweets that go like "wow, it is so awesome...". I'm sorry, I am not a native english speaker and don't know the correct definition of awesomeness, but I *absolutely* don't care if something is _awesome_. I am using raven because working with it is faster, cleaner and produces less troubles compared to when using SQL Server. In the end, it saves budget and I run into less headaches. This is why _I_ use raven. Sure, the relational/document-oriented mindshift hits you hard. Really hard. Even though RavenDB tries to hide a lot of the complexity from beginners and rewards your first efforts with some 'it just works' moments, you still have to go a steep learning curve if you want to use it in more complex scenarios. RavenDB is not for everyone. I know that because I regularly need to explain what an ORM is and why not to write plain SQL in code (VB of course). I mean, these guys have 'software engineer' on their business card. No, Raven is not for them. For the rest of us (those reading blogs like this one) I think it is definitely worth the effort to learn about document modeling and how drastically it can simplify your daily business.

njy commented on Embracing RavenDB

Wed, 01 Feb 2012 21:40:27 GMT

@Ryan: "Ayende has a search box at the top right corner" Thanks! Wow! Now i can add "able to use search box in Ayende's site" on my resumé :-) ! Ok, jokes apart: it is clear to you that i'm *not* asking here for *a* specific answer to *a* specific question? Instead i'm proposing to group together some specific "general" issues that people coming from rdbms land may have, the main doubts that they may have, and put them in a single place. And i'm asking here because Oren talks about this stuff, one time here, one time there, and it may be useful to group them together. Oh, and because Oren has a company, which in turn makes a product called RavenDB, which in turn may benefit from this kind of operation. Cheers.

njy commented on Embracing RavenDB

Wed, 01 Feb 2012 21:27:48 GMT

@Ryan: maybe i didn't make myself clear. First thing: i've not said that those topics were *all* uncovered as of today, on the contrary: some of them have been covered, but there is not a single page/place to look at, and since RavenDB is a product, i suggested it would be good for it (and, as a reflex, maybe for the whole nosql movement too). Second: sometimes devs aren't dictators, sometimes there's a dialogue between devs and dbas, because their experience actually does matters, too (imho). So, if you should have a discussion, their topics and fears should be covered too, stuff that (maybe) devs normally don't take into account, like backup policies or maintenance plans. On top of that a nosql-like solution may be the only possible choice (think facebook, just as a silly example) but some other times either an rdbms or a nosql solution would see fit, but going through the nosql way with some "holes" along your path may hurt, so better talk in advance and be prepared. We're just discussing here, i think that's useful. Other stuff: "it's just POCO" yeah, i got it, but you may want to work on the data to "play around" or "test different data designs" and you may don't want to be forced to create a test console app to do that. You may want to prototype stuff or see how a model will work in a doc db, trying to than query it to see results, or I may want to trow some queries and see how the system works, that is a use for a queryanalyzer-like tool. Anyway the answer for that is that there's a query tool inside the webadmin for RavenDB, so that's ok. Regarding "no joins": you shuld tell Oren, because he talked about that (see this http://ayende.com/blog/4661/ravendb-live-projections-or-how-to-do-joins-in-a-non-relational-database ). For backup: yeah, i read that part. I repeat: i was trying to make a list of possibile arugments to clear up for people coming from the RDBMS world wondering if *everything will be doable and fine* in this new NOSQL world. Maybe all in one page/place, and not scattered through 20 posts in multiple blog. You guys see this as useful? Good! No? That's fine, we'll survive :)