Forgot your password?
typodupeerror
Databases Facebook Technology

Digg Says Yes To NoSQL Cassandra DB, Bye To MySQL 271

Posted by timothy
from the can-you-trust-a-db-by-that-name? dept.
donadony writes "After twitter, now it's Digg who's decided to replace MySQL and most of their infrastructure components and move away from LAMP to another architecture called NoSQL that is based in Cassandra, an open source project that develops a highly scalable second-generation distributed database. Cassandra was open sourced by Facebook in 2008 and is licensed under the Apache License. The reason for this move, as explained by Digg, is the increasing difficulty of building a high-performance, write-intensive application on a data set that is growing quickly, with no end in sight. This growth has forced them into horizontal and vertical partitioning strategies that have eliminated most of the value of a relational database, while still incurring all the overhead."
This discussion has been archived. No new comments can be posted.

Digg Says Yes To NoSQL Cassandra DB, Bye To MySQL

Comments Filter:
  • Nothing new ... (Score:2, Interesting)

    by tomhudson (43916)
    Cassandra is basically a sloppy implementation of UniVerse and elated products. Why sloppy? Because the idea of a separate file access for each column sucks - use a union or struct as necessary, people!
    • I too have a site running on MySQL and I am thinking of switching.

      Can anyone tell me if there is any "comparison chart" listing the various features / usability of the various OSS DB packages available so I can make a better educated decision?

      Please help !

      Thank you !

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        If you need a comparison chart... you don't need to switch.

        It's probably not necessary to change such a huge part of your architecture if it's not worth investing serious time investigating and benchmarking the alternatives.

        • by Taco Cowboy (5327)

          Thank you for the reply.

          It's not "switching for switching sake".

          The reason for switching is simple: When my site first launch, MySQL is more than enough for it.

          As it grows and grows, it's taxing MySQL more and more and right now it's already at the brim.

          So ... Anyone has any info on where to look for a "comparison chart" or anything like that?

          Please help !

          • by h4rr4r (612664) on Friday March 12, 2010 @11:34PM (#31461092)

            Postgres, for people who care about their data.

          • Re: (Score:2, Insightful)

            by larry bagina (561269)
            you should probably look at what queries you're running and what the planner/optimizer is doing with them to verify the problem is mysql and not your schema and indexes.
          • by itzdandy (183397)

            What is at the brim? do you think that you have a performance issue? Considered a master/slave/slave/etc cluster? Do you do a ton of reads and few writes or many writes?

            It's hard to say that mysql is at the brim without some explanation.

          • by RelliK (4466) on Saturday March 13, 2010 @12:13AM (#31461362)

            Go with PostgreSQL. Reliable, standards-compliant, fast.

            • Re: (Score:3, Insightful)

              Note: Facebook, twitter, digg: they aren't moving to postgreSQL. Its not better enough to make any kind of difference for that kind of a scale. They don't need features, they need speed.
              • by QuoteMstr (55051) <dan.colascione@gmail.com> on Saturday March 13, 2010 @01:20AM (#31461720)

                First of all, if he's asking Slashdot for advice (which is barely a step above reading tea leaves [which itself is a step above asking 4chan]), he doesn't need Facebook-level scalability.

                Second, you're confusing scalability and performance. Scalable solutions tend to actually be slower than non-scalable ones: the difference is that a scalable system increases in capacity linearly with the number of machines you throw at it ("horizontal" scalability), whereas a fast non-scalable system generally needs the same number of faster, individual machines to increase capacity ("vertical" scaling).

                Third, PostgreSQL has excellent performance, and PostgreSQL does, in fact, scale horizontally [postgresql.org].

                • Re: (Score:3, Informative)

                  While insightful and informative in its own right, that isn't a logical response to my post.

                  He was asking for an alternative to Mysql. I was pointing out that moving from mysql to postgresql was not done by large companies with a lot of smart people working for them, because any performance improvements were not worth it.Postgresql's vertical and horizontal scalability did not represent an improvement over mysql. I didn't even mention vertical vs horizontal scalability. In the end you end up with a raw numb

              • by Billly Gates (198444) on Saturday March 13, 2010 @02:51AM (#31462152) Journal

                PostgreSQL is a real relational database that support views, nested sql, triggers, foreign keys, and even statistical analysis.

                I think Mysql supports foreign keys now and my info might be dated. But if a database does not support foreign keys then its not a real relational database and mysql had that problem for years [slashdot.org].

                Once switching over you can find out how hard processor intensive tasks that took minutes can be done easily in seconds with the features I described above with PostgreSQL. You can save alot of speed with complex queries with PostgreSQL.

              • by TheLink (130905)
                You have to figure out whether your company and user base are the sort that might grow fast or not.

                If you're only at the "brim" now with MySQL and you are only growing 10-30% every year, just switch to a better RDBMS product and your needs might be well taken care of by Intel, AMD, Broadcom, Cisco and the SSD/storage manufacturers for the next 5-10 years.

                If you are growing really fast, then sure you need something that really scales well horizontally. Horizontal scaling comes at a cost though.

                Just look at f
            • by alexkorban (627031) on Saturday March 13, 2010 @03:58AM (#31462404) Homepage
              I have worked with large PostgreSQL databases (150GB or so) and really, Postgres isn't a solution. You run into issues anyway when some of your tables contain millions or even billions of rows. At that stage things like vacuuming or altering the schema start to become damn near impossible, and even querying starts to become a bottleneck.

              Now how do you scale that if your database is still growing? Postgres doesn't have a decent clustering solution that I know of, so your options are either to roll your own, or to scale vertically. Both of those are expensive options.

              Based on my experience, I don't think that relational databases are appropriate for really large databases, and at present the only realistic option is horizontal scaling which is a lot easier with things like Cassandra or MongoDB.
              • Re: (Score:3, Informative)

                by roman_mir (125474)

                I just read your comment and checked the PostgreSQL DB I am working with, it's only 1.7GB at this point, but growing, and the most rows in a table is 12,6 million. This DB is heavily used by a number of background processes, which select, insert, update and delete large volumes of data and by 14 people at this point, who run about 400 various reports per day each as well updating some data. The average time that a single user has to wait is 6 seconds per report. Those reports are optimized of-course, but

              • Re: (Score:3, Informative)

                by DarkOx (621550)

                A good RDBMS engine and as much as people Poopoo MSSQL server its a good engine. I have used it for databases in the 150TB range. If you do your schema right, your indexes correctly, plan your partitions and file groups well you can great performance out of affordable hardware. Now you do need to maintain this thing or develop the automation around building those partitions and moving data into and out of them based on tombstones or some other criteria or your get underwater real fast.

                I don't care what t

      • by toastar (573882)

        So what's the advantage of switching?

        I have a policy of if it ain't broke don't fix it

        • by Miseph (979059)

          Presumably the advantage is that what they have now doesn't work well and that they are concerned it will continue to work less and less until some arbitrary point in the future where they would have to declare it no longer works at all, and that what they're changing to seems to resolve the issue.

          Call me crazy, but I'm pretty sure that somebody at Digg is aware of that particular catchphrase.

          • by berzerke (319205)

            ...Call me crazy, but I'm pretty sure that somebody at Digg is aware of that particular catchphrase...

            Well, I've seen switches to new software and OSs because a new exec decreed it, regardless of how well what they had was working. Could be he (or she) got kickbacks, or some smooth talking salesman pulled the wool over his eyes, his son got a job with the new company, etc. Change is sometimes made for political reasons rather than technical ones.

            While I see no evidence that was the case this time, it has

        • Re: (Score:2, Insightful)

          by mysidia (191772)

          A bad policy when dealing with your data.

          Once it's broke, it is way too late.

          You can't un-LOSE the past 6 hours of transactions or table referential integrity that MySQL trashed, due to an unclean shutdown.

          MySQL's great until it comes up to bite you in the arse.

      • The whole NoSQL concept takes a little getting used to. I'm not knocking by any means, I've just been using the whole relational model for decades and need to digest this new approach before I can fully embrace it.

        You can try this wiki page [wikipedia.org] for an explanation of the concept.
        • by QuoteMstr (55051) <dan.colascione@gmail.com> on Friday March 12, 2010 @11:47PM (#31461190)

          The page you cited, on column-oriented databases, describes an implementation strategy that's applicable to many types of databases. There are database engines that present a perfectly normal SQL interface to a column store, and there's actually a direct link to LucidDB [wikipedia.org] from the article. Likewise, there's nothing stopping a Cassandra-like database from serializing its on-disk bits the other way around.

          Column-orientation has nothing to do with the "NoSQL" databases that are in vogue. It's completely orthogonal. You're talking about using vectors or linked lists when everyone else is arguing over whether to serialize data with XML or JSON.

          • So much horseshit in just one slide deck. No matter what you do, unless you have at least a hundred machines at your disposal, Hadoop won't be faster than a single box grep from SSDs. LucidDB is excruciatingly slow for all but tiniest datasets. I've tried a good half dozen "solutions" from this slide deck (including Aster), and other than Postgres all of them suck ass, more or less. If you see ANYTHING other than Nutch with Hadoop as a backend, head for the hills right away.

    • Re: (Score:3, Funny)

      by FooAtWFU (699187)

      UniVerse and elated products

      Yes! These products are wonderful! They are spectacular! They are a beam of sunshine refreshing my soul! I'm so happy with them! Daisies!

    • Seriously, are these like Universe products? I'm working in Unidata on a project, and you're right, it f'ing blows.
    • Re: (Score:3, Interesting)

      by hibiki_r (649814)

      Come on, it cannot be any sloppier than actual UniVerse: It performs extremely poorly on large files, especially when record sizes vary wildly. I've seen in-memory files in which any insert or update operation took 5+ seconds! In my experience, even Postgres in far weaker hardware just spanks UniVerse even on the simple queries where it should have an advantage. If you ever need to read two or three files, either by hand or through I dictionary entries, UniVerse is orders of magnitude slower. When you add t

  • by clarkkent09 (1104833) * on Friday March 12, 2010 @10:53PM (#31460736)
    In other news, Cassandra developers are celebrating the fact that their database is now used to store the largest amount of worthless information in history.
    • Re: (Score:3, Insightful)

      by DigiShaman (671371)

      I used to think that also applied to Slashdot. But no, I've learned a lot both directly and indirectly over the many years (ten years, wow). Even if most of it is crap, the debates and discussions are still quality entries worth keeping.

      • Re: (Score:3, Funny)

        by OakDragon (885217)

        In other news, Cassandra developers are celebrating the fact that their database is now used to store the largest amount of worthless information in history.

        I used to think that also applied to Slashdot. But no...

        Correct - Slashdot doesn't use Cassandra!

    • by h4rr4r (612664) on Friday March 12, 2010 @11:35PM (#31461110)

      Fits, before that mysql was the best way to store data no one cared about.

    • Re: (Score:2, Insightful)

      by OnlyJedi (709288)

      According to various internet sources (so take with a grain of salt):
      Mark Zuckerberg's net worth [wikipedia.org]: $2 billion. Made entirely from Facebook.
      Twitter's net worth [venturebeat.com]: $589 million.
      Digg's net worth [websiteoutlook.com]: $24.34 million.

      Even if each individual datum is nearly worthless, the combined value is far from it. Do you think any of those companies would still be worth what they are if they're databases were irretrievably wiped?

      • by QuoteMstr (55051)

        Made entirely from Facebook.

        No. It was made by schmoozing investors. None of companies you list has ever turned a profit.

        This is the kind of reckless behavior that leads to financial bubbles. Pay should be much lower initially. I doubt Zuckerberg would have worked any less hard (or hacked any fewer email accounts) if he had been paid the mere subsidence wage of $1 million per year.

        • I doubt Zuckerberg would have worked any less hard (or hacked any fewer email accounts) if he had been paid the mere subsidence wage of $1 million per year.

          Entrepreneurs are a funny breed. It's the extreme risk and reward - the prospect of riches just around the corner that drives them, not the daily feed bag (which keeps corporate drones climbing the ladder). Or course $1M/year is a lot of dough but it doesn't matter what the number is, once it's rolling in steady the motivation is gone. In other words, I

          • by QuoteMstr (55051)

            Are you seriously arguing that unless the first derivative of one's salary is positive, there's no incentive to work?

            • by Pojut (1027544)

              Unfortunately, this is in fact true for many people -_-;;

            • by seanadams.com (463190) * on Saturday March 13, 2010 @12:24AM (#31461430) Homepage

              Are you seriously arguing that unless the first derivative of one's salary is positive, there's no incentive to work?

              No, I did not say that one's salary needs to be monotonically increasing. That is not the point at all. And did you really have to turn this into a calculus problem?

              To state it differently, many entrepreneurs are willing to work temporarily for little or even nothing, and to make great sacrifices such as giving up health benefits, vacations, and normal family/social life... things most 9-5 workers would never consider. Being someone's bitch for $1M/yr (or to be pedantic let's say $1M/yr + 5%/yr^2) may sound like a splendid deal to you but there are others who would work much harder for sweat equity in their own venture.

              These people exist even if you can't fathom it. I'm one of them.

              • Re: (Score:2, Interesting)

                by QuoteMstr (55051)

                Let me ask the question a different way then: which particular tasks related to founding a company would you personally perform in exchange for $2 billion, but not in exchange for $1 million? Would you work longer hours? Talk to your family less?

                I cannot conceive of incentive to work increasing appreciably after about $1 million. We can talk about the exact figure, but clearly $2 billion is ludicrous for a private individual.

                Excessive compensation is rent seeking [wikipedia.org] and harms society in numerous ways: it disto

                • Let me ask the question a different way then: which particular tasks related to founding a company would you personally perform in exchange for $2 billion, but not in exchange for $1 million? Would you work longer hours? Talk to your family less?

                  Would I prefer $1M now vs $2B later? Are you seriously that obtuse, or have I been trolled?

                  Do you have any notion of what the "tasks related to founding a company" even are? Just some legal paperwork, I suppose?

      • Re: (Score:3, Funny)

        by jo42 (227475)

        Sorry, I just can't resist...

        > databases were irretrievably wiped

        The expression to describe such an fortunate event would be "and nothing of value was [would be] lost".

      • The risk is not total loss of the entire database but occasional corruption here and there. However, for Facebook that's tolerable as long as it doesn't rise to a level such that it irritates the users. Given that the average Facebook user can't remember her best friend's phone number, that's a pretty high level.

      • Digg's net worth [websiteoutlook.com]: $24.34 million.

        Makes me wonder why its owners put so much effort into making it suck. Their discussion system used to be half decent. Then they changed it and it is totally useless again.

    • Re: (Score:3, Informative)

      by prockcore (543967)

      Reddit also switched from memcachedb to Cassandra for their kvstore. From research to launch took 10 days.

  • Reddit (Score:4, Informative)

    by Gudeldar (705128) on Friday March 12, 2010 @10:54PM (#31460748)
    Reddit also recently switched [reddit.com] to Cassandra.
    • by jibjibjib (889679)
      Just for persistent cache, not for their main database.
    • Will Slashdot switch?
    • by Anonymous Coward

      On a related note, Reddit's performance and reliability has dropped off significantly since switching to Amazon's "Cloud", and dropped off even further after this switch to Cassandra.

      The constant 503 errors, plus horrendous load times when it does manage to work, have driven me and many others away from Reddit. That's why I'm posting here on Slashdot.

      Cloud hosting is a stupid idea for anything beyond a blog getting 10 hits per date. All the talk about scalability is pure bunk. I mean, even with the extensiv

      • by uncqual (836337) on Saturday March 13, 2010 @01:25AM (#31461754)
        One aspect of the "cloud" (as in EC2) is that you can not only scale up easily (for $ of course), you can scale down easily (to save $).

        When you have fixed "in house" infrastructure to handle peak loads, there's not a lot of motivation to power off absolutely as many servers as you possibly can when you're not at peak load - all you save is the energy costs (and, if you're using remote hosting, you don't get rewarded for this except for whatever value you attach to feeling "green"). You still pay for the floor space, the machines, and perhaps some sort of maintenance contracts regardless of if the server is powered up or down.

        Using EC2 (depending on how you've structured it - some dedicated, some non-dedicated instances etc), if utilization drops to 80% over 20 instances, the temptation is to release a couple instances to save a couple bucks and drive utilization up to 90% on the remaining instances -- with potentially unfortunate consequences.

        Although I have no idea, I wonder if Reddit is just releasing instances too aggressively now "because they can" in order to save money? If so, the fingrer should be pointed at Reddit, not the cloud (or EC2 specifically).
  • I imagine with the continual growth of these social networks, high performance DB methodologies will experience tremendous growth, and perhaps even paradigm shifts in the way we logically think and design database architectures. Instead of this flat 2D table mentality, imagine n-dimensional matrices of data, scaling dimensions instead of table and rowcounts.

    I bet if you converted Facebook to this n-dimensional 'table' model, and did a couple inner-joins and unions, you could rip space-time wide-open!
    • Re: (Score:2, Interesting)

      by DogDude (805747)
      I imagine with the continual growth of these social networks, high performance DB methodologies will experience tremendous growth, and perhaps even paradigm shifts in the way we logically think and design database architectures.

      Your statement that social networks push databases to their theoretical limits is laughable. Larger, more frequently accessed, more complicated databases have existed for years (decades?) before the current crop of Friendster clones existed. Just because Facebook is the largest,
      • Re: (Score:3, Interesting)

        by Anpheus (908711)

        Now, I'm not an expert on database use and don't want to come across as sarcastic, but it's my impression that a lot of the questions that are being asked of these new types of databases simply don't have past analogues, or if they did, they were solved with this sort of approach in an RBDMS, basically using an RBDMS but without the relational part. Hadoop, Google, and all these social networking sites surely aren't all just... confused? Are they?

        Please elaborate on how an RBDMS is applicable to what I gues

  • Away from LAMP? (Score:3, Insightful)

    by Anonymous Coward on Friday March 12, 2010 @10:58PM (#31460780)

    Or away from MySQL? There is a difference.

    • LAMP stands for "Linux Apache MySQL PHP". Moving away from MySQL IS moving away from LAMP. In this case, they seem to be moving to LACP. If they had moved to PostgreSQL it might be termed LAPP.
  • by mgkimsal2 (200677) on Friday March 12, 2010 @10:58PM (#31460784) Homepage

    From the Digg blog - http://about.digg.com/node/564 [digg.com]

    "And if that doesn't sound like a big enough challenge, we're replacing most of our infrastructure components and moving away from LAMP."

    Cassandra Linux Apache PHP?

    • Re: (Score:3, Funny)

      by Anonymous Coward

      Trust me, you don't want the clap!!!!

    • by solferino (100959)

      This reminds me of the original name for the Daihatsu Applause, before they did their complete model name reaction testing.

    • Re: (Score:3, Funny)

      by Tablizer (95088)

      [...moving away from LAMP] Cassandra Linux Apache PHP?"

      try: Cassandra Ruby Apache PHP
         

  • This sad thing is that Monty's MySQL fan boys will blame this on Oracle when in reality the move to Cassandra (or other NoSQL databases) is what a lot of web sites should be doing regardless of who holds the MySQL reins.

  • i can't tell from the 4 lines of text buried in ads that is this supposed article, but i'm guessing this "nosql" still uses an sql database backend?

    and why wouldn't a relational database system not be perfect for facebook?

    • Re: (Score:3, Informative)

      by Anonymous Coward

      i can't tell from the 4 lines of text buried in ads that is this supposed article, but i'm guessing this "nosql" still uses an sql database backend?

      and why wouldn't a relational database system not be perfect for facebook?

      1) NoSQL databases are just that NO SQL, there is no relational database involved.

      2) No relational models are not good for Facebook style data, Facebook uses a lot of trees, networks and graphs, none of which are easy to store in a relational system, Facebook also has a lot of dynamic schema requirements, again SQL does not cope with this well, and at the scale that Facebook operates at they are forced to use techniques like sharding and partitioning of their data sets, at which point a lot of what makes th

  • by QuoteMstr (55051) <dan.colascione@gmail.com> on Friday March 12, 2010 @11:39PM (#31461136)

    These slides [pgexperts.com] present a balanced and comprehensive overview of the current state of free databases. Whether you're in the NoSQL camp or not, they're worth reading.

    That said, here's my take:

    It's currently fashionable to replace MySQL with some "NoSQL" database or other. This trend is driven by two factors:

    • MySQL's community is fragmenting into several forks as Oracle purchases the rights, which created the impression that MySQL's development is entering a riskier, unstable period.
    • "NoSQL" is the technology buzzword du jour in the Bay Area. It's difficult to overstate the impact of social forces on technology choice: most technology selections are governed more by what our friends say than by an impartial and disinterested weighing of merits.

    I haven't seen any consideration from potential "NoSQL" adopters of the benefits of using a good relational database like PostgreSQL. There's a world of difference between it and MySQL, and condemning all relational database systems because of bad experiences with MySQL is like condemning all sandwiches because McDonalds once made you sick. In giving up RDBMSes entirely, these developers lose quite a bit of safety, flexibility, an convenience. It's a huge over-reaction.

    This field should not be about following trends, though unfortunately, that's how most people choose which technologies to use: it should be about choosing the best tool for the job. And I believe that in the vast majority of cases, the advantages conferred by a relational system --- enforced integrity, interoperability based on SQL, query flexibility, storage flexibility --- make an RDBMs the best choice for almost any job. If you need sloppier semantics for some cases (for example, "eventual consistency"), you can layer that on top of a robust RDBMs.

    • Re: (Score:2, Offtopic)

      by nextekcarl (1402899)

      I think it comes down to the sad fact that most people aren't good at their jobs. They tend to rise to one level above where they are actually competent, and stay there. And from my experience, they aren't usually very happy in whatever that position is, which (and IMHO) might be the reason that people in modern societies are often less happy (overall) than people in less advanced societies. Not many people enjoy that.

      • by timmarhy (659436)
        go live in a mud hut then if it'll make you happy (i suspect it wont).

        society isn't miserable, it's the media telling us we are miserable that has people thinking it. just look at how every single event has to be a crisis or the worst ever of something. and then, a word from our sponsors who sell product X that is the cure for what ales you.

        if you want to destress and be happy, go on a total media black out. it's amazing how much less pressure you feel and happier you are if you refuse to read the news or

        • by QuoteMstr (55051)

          Actually, compared to people in industrial nations like ours, hunter-gatherers are happier and have more leisure time. After all, that's the environment to which we're biologically adapted. You can make a serious argument that agriculture is the worst thing to ever befall humanity.

          • Its not only that we have less leisure time but the fact that our worth is based on money. Inflation is very high if you count insurance, food, rent/mortgage, and gas prices (economists don't count this) and depressing wages and you have misery.

            There is always someone richer than you who is busy trying to take away what you have.

    • by TubeSteak (669689) on Saturday March 13, 2010 @01:58AM (#31461908) Journal

      I haven't seen any consideration from potential "NoSQL" adopters of the benefits of using a good relational database like PostgreSQL.
      ...
      If you need sloppier semantics for some cases (for example, "eventual consistency"), you can layer that on top of a robust RDBMs.

      When you're dealing with TB/PB of data that doesn't require relational capabilities, there's no reason to use a "good relational database like PostgreSQL" when you can dispense altogether with the relational aspect and its performance hit.

      NoSQL may seem like the fad-de-jure, but until recently, nobody was working with such enormous dynamic datasets. When you look at the growth of all these hi-tech companies, they did an incredible amount of in-house hacking to develop the software necessary to glue together their enormous hardware infrastructure.

    • by kmike (31752) on Saturday March 13, 2010 @03:10AM (#31462230)

      As several MySQL experts already noted, Digg isn't even using the indexes that provide maximum performance in the query that they present as problematic for MySQL:
      http://mysqlha.blogspot.com/2010/03/index-only.html [blogspot.com]
      http://www.yafla.com/dforbes/Getting_Real_about_NoSQL_and_the_SQL_Performance_Lie/ [yafla.com]

      So you are right about the NoSQL fashion trend. Looks like for some companies it's easier to throw a pile of cheap commodity hardware driven by some NoSQL BigTable-wannabie at the problem instead of carefully optimizing queries and indexes for the best performance.

    • by jrumney (197329) on Saturday March 13, 2010 @03:20AM (#31462268) Homepage

      I haven't seen any consideration from potential "NoSQL" adopters of the benefits of using a good relational database like PostgreSQL.

      The adopters of NoSQL deal with huge volumes of worthless information. They don't care about transactional integrity as much as they care about performance, which is why they chose MySQL over a good relational database in the first place.

    • by scribblej (195445)

      While I agree with you, I'm a developer of ... medium-sized systems using Postgresql, and this article greatly piqued my interest, considering the single biggest problem I've had with Postgres is it's lack of any good replication or redundancy methods. Right now I tend to use WAL replication to a "warm-standby" server, but this is hardly ideal in any sense.

      Don't misunderstand me, I dearly love Postgres. It's just the replication where it really falls flat. Yes, I am aware of all the projects like Slony a

  • MySQL has never been a good example of a relational database, the underlying implementation is limited. Its MySQL that is the problem here, not relational databases.

    I suspect here that it is not the relational model at fault here, but the lack of creativity and competence in implementing a relational database technology. MySQL perhaps has never been a particularly scalable platform, it has a number of severe limitation and does not seem to be designed with a lot of thought for a distributed environment. Its

    • Mysql sucked for many years but is getting better with each release. It was never designed to be a fully RDBMS .

      In Japan people use PostgreSQL and I am surprised that its not common among geeks. Many ISPs now offer it as well as MySQL. The problem is the trendy word is Nosql and mostly non database programmers are promoting the movement due to bad experiences of trying to learn mysql to do things that are very complicated.

      PostgreSQL is very easy to switch your existing code too if you used SQL compliant cod

    • by FlyingGuy (989135)

      If you want to scale without limits and have the money to pay for it buy Oracle.

      If you want to scale with a few limits, but don't have any money get Postgres

      If you want to play around and write some of the most stupid syntax on the face of the earth then play with any of the afore mentioned text databases.

  • "NoSQL"? (Score:5, Insightful)

    by Stan Vassilev (939229) on Saturday March 13, 2010 @12:27AM (#31461446)

    Am I the only one who frowns at this moniker?

    First, it creates a false premise where people need to pick "SQL" versus "no SQL", while many real-world systems intelligently combine relational and non-relational data storage for their needs. There is no conflict.

    Second, there's nothing wrong with SQL as a language in particular, and in fact many of the "noSQL" engines are starting to support and extending basic SQL queries, instead of reinventing their own query language for the same purpose.

    I suppose "lessRDBMSabuse" was less catchy...

    • It's "Not Only SQL" (Score:4, Informative)

      by Otis_INF (130595) on Saturday March 13, 2010 @05:02AM (#31462620) Homepage

      The 'n' stands for 'Not' and the 'o' stands for 'Only', so it's wrong to read it as NO SQL, it should be seen as Not Only SQL. I.o.w.: not a move away from sql, but exploring other options besides SQL

    • Re: (Score:3, Informative)

      by shic (309152)

      Second, there's nothing wrong with SQL as a language

      I beg to differ - SQL is preposterously baroque!

      That said, if you're problem is of a particular kind, it is a perfectly reasonable, practical, solution to many problems.

Life. Don't talk to me about life. - Marvin the Paranoid Anroid

Working...