HN user
To be fair, some NoSQL solutions were being sold marketing wise as the be-all and end-all of data solutions. Just google "mongodb mysql migration" and look how everyone is/was so eager to jump on the non-relational bandwagon. Some backlash was to be expected, after all, we might have reached the Trough of Disillusionment
Data centers usually can be considered a long term type of thing and I´m pretty sure that Google is not going to build a "smallish" one, but I see your point regarding bandwidth and links.
You seem to imply that Brazil may be lacking political stability, infrastructure and/or trained professionals, but I don´t know to what extent this would be true. You have to consider that, aside from the economy, Brazil has up to 34% of all latin american population with the vast majority of it living on the eastern coast line. Placing a data center on the west coast does not add up.
There might be some other underlying reason why Google decided to settle in Chile. Maybe the cooler climate can reduce their operational costs.
Wouldn´t it make more sense to build it in Brazil given the potential market?
The creator of Lemon is Richard Hipp, the same guy behind Fossil, SQLite and (the probably now defunct) UnQL
I´m not necessarily defending the movie, but I don´t think that Janek actually "solved" it, but I do think that that´s what they want us to believe. The black goo is not an weapon IMHO, but a way to accelerate the evolutionary process in a planet, bringing forth more adaptable lifeforms (without preserving the previous ones). That´s what is shown in the beginning of the movie. The engineers could be responsible for rapid evolutionary bursts throughout the history of our and other worlds.
Perhaps we, as a species, weren´t simply done yet. Something still had to burst out our collective chests in order for us to actualize our genetic potential. Maybe the xenomorphs were the ultimate monkeys out of which the definitive mankind would evolve from.
Piss poor execution though.
I understand the necessity of writing the couchstore component in C for performance, but in what ways does it differ from the storage engine? In other words, why have 2 different things doing apparently the same thing?
I´m curious to see how this cluster aware incremental map/reduce performs in "web scale" workloads.
Looking forward to see more of this.
p.s.: Is there a roadmap?
It could have a sharding aware data definition language and some support for "on-the-fly" data migrations.
You made me think about something. A CoffeeScript like approach to build a saner language that would sit atop SQL would be something definitely worth having. Maybe this could be the start of the "OnSQL" movement. Just my thoughts.
what parts? I'm interested about the future of Couch(Base|DB) sans all the Apache wankery.
I really wish you'd take more of a BDFL approach to things.
I'm curious. Would be willing to elaborate a little more?
but aren't nodes supposed to crash, albeit in a tolerable way? Even though I conceptually like Riak I haven't tried it yet, because the problems that I deal with aren't worth the trouble of setting up a cluster and managing it.
I think that the cluster is supposed to be stable. The nodes, not so much.
In Brazil there is a saying, "água mole em pedra dura, tanto bate até que fura", which means something like "Soft water on hard rock will eventually poke holes in it", but it sounds way less folksy than the original.
But if it absorbs IR and irradiates a considerable amount of heat at the same time, wouldn't it be considered a lousy, lousy IR absorbent?
If it is cheap enough, it could be used to easily bypass infrared motion sensors.
and what would that subset be in your opinion?
I´d like to ask the Couch luminaries that hang around here about the status of the inclusion of Google´s snappy compression library and the rewrite of the view engine. I´m aware that we are talking about a Cloudant specific solution here, but how much of an impact would it have in a scenario such as the one described in this talk?
and it is a easily trollable target as well. Had he tried to to attack durability on probably any other database, it probably would not have worked as well as it did.
Whether its a troll attempt or not, remains to be seen, but I completely agree with this specific, albeit very generic, part of the text.
> Databases must be right, or as-right-as-possible, b/c database mistakes are so much more severe than almost every other variation of mistake. Not only does it have the largest impact on uptime, performance, expense, and value (the inherit value of the data), but data has inertia. Migrating TBs of data on-the-fly is a massive undertaking compared to changing drcses or fixing the average logic error in your code. Recovering TBs of data while down, limited by what spindles can do for you, is a helpless feeling.
It´s worth asking. Zed?
and now he is openly trying to discredit himself. He is either a troll with a conscious or his cloak of anonymity is wearing thin
I feel like a dick, but I have got to ask. Is it Disney? Disney is on both the couchbase and 10gen sites. Both sites mention that they are using their NoSQL solutions to power their social and online games. Couchbase powers Zynga and can arguably be considered the leader on this specific market. Am I close?
I feel that Couch has too much server side programming. It can be off puting sometimes. If anyone wants to make some money, I'd suggest them putting a server on top of a couch cluster that receives mongo queries.
I mean, how hard can it be to
1) Manage some indexes,
2) Keep some metadata around and
3) Build some half-assed single index query planner?
Couch is already a solid piece of technology. It just needs a better API to "sit" on top of it, kinda like what Membase is doing now.
edit: or on top of Riak, Cassandra, PostgreSQL or etc ... on the API side, Mongo has clearly won.
One of the things that I love about Couch is that the standard way to shutdown the process is simply doing a kill -9 on the server process. No data loss. No Worries. Want to back up your data? rsync it and be done with it.
Couch may have its warts, but it is damn reliable.
Given the current discussion about MongoDB, I think that the following post is worth revisiting.
http://news.ycombinator.com/item?id=2538037
I'm not a Riak user, but I agree with Basho's analysis on this case.
I'm curious and I might be missing more than half of my brain. Would you be willing to show some examples of bad coding on their source tree?
Godwin's law - As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1.
I'm sorry he didn't get to order another batch from Issey Miyake
MongoDB, the "blame the user" database