Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"SQLite is not designed to replace Oracle. It is designed to replace fopen()."

sqlite.org

Post reply on HN
Print view View original

51–58 of 58 posts

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#51

Post by karambahh »

jacques_chester wrote: post #34
karambahh wrote: post #33

Earlier quoted context omitted.

When you need multiple spatially distributed active/active write nodes (multiple masters...) you pretty much need Oracle RAC. When confronted with the cost, you end up designing something where writes are pushed to a caching layer, which deals with an active/passive setup, with enough buffer to switch passive to active if something goes wrong.

DB2 and Teradata boast comparable degrees of horizontal, multi-site scalability.

And DB2 cost pretty much the same as Oracle... :p

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#52

Post by skrebbel »

wheels wrote: post #48
StavrosK wrote: post #44

Earlier quoted context omitted.

I worked with a thirty-million-row dataset for my thesis (after MongoDB famously choked and ate half my data more than once) with SQLite and it didn't bat an eyelid. It was fast as hell, too.

Size isn't the problem with SQLite databases. It's that it's unbearably slow with even fairly trivial joins and most of the other operations where it'd make sense to actually have an SQL database. SQLite is fine for tabular data, but then, so are a bazillion other things. Basically it's the perfect SQL database for the times that you shouldn't be using an SQL database.

> Basically it's the perfect SQL database for the times that you shouldn't be using an SQL database.

Well, that comment resonates with me. I feel the same but can't support it well with arguments. Care to share what you would use instead? F.ex. to replace fopen() with like the OP describes.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#53

Post by jacques_chester »

karambahh wrote: post #51
jacques_chester wrote: post #34

Earlier quoted context omitted.

DB2 and Teradata boast comparable degrees of horizontal, multi-site scalability.

And DB2 cost pretty much the same as Oracle... :p

Less, usually, depending on the platform. IBM mostly uses DB2 to sell its fancier hardware.

But occasionally you gotta spend money to make money.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#54

Post by microtherion »

wheels wrote: post #48
StavrosK wrote: post #44

Earlier quoted context omitted.

I worked with a thirty-million-row dataset for my thesis (after MongoDB famously choked and ate half my data more than once) with SQLite and it didn't bat an eyelid. It was fast as hell, too.

Size isn't the problem with SQLite databases. It's that it's unbearably slow with even fairly trivial joins and most of the other operations where it'd make sense to actually have an SQL database. SQLite is fine for tabular data, but then, so are a bazillion other things. Basically it's the perfect SQL database for the times that you shouldn't be using an SQL database.

I don't quite agree with that. One advantage I see for using SQLite is that you CAN use it as an SQL database for administrative purposes: You can quickly import/export the data from or into another SQL database, you can quickly generate an ad hoc report, etc.

So to me, the SQLite use case is often where the PRIMARY purpose of a database could be served nearly as well with fopen(), but where it's likely that there will be SECONDARY uses for which having a convenient universal access method would be useful.

I've even considered writing an external table plugin for SQLite to facilitate diagnostics and reporting of a complex ad-hoc file format I designed so I could get those benefits with a custom data structure; unfortunately, doing that seems somewhat complex in SQLite.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#55

Post by Muzza »

k33l0r wrote: post #36
Muzza wrote: post #27

Earlier quoted context omitted.

Linus is a native speaker of Swedish, not Finnish.

The pronunciation of 'Linus' is pretty much the same in Swedish and Finnish, though.

Surely the U differs. To Sweden-Swedish ears at least, Linus in Finnish sounds like Linos.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#56

Post by kellishaver »

lsb wrote: post #22
kellishaver wrote: post #18

Earlier quoted context omitted.

This surprises me. Though I've used it with great success for several small projects, my only experience with SQLite on anything remotely large was a Rails app with maybe a million records in the DB. Over time, performance became very slow and switching to MySQL made a world of difference. At the time, I attributed it to SQLite, but now I'm wondering if it was Rails or (more likely) my inexperience at optimizing perf…

In SQLite, autocommit is on, so if you weren't explicitly setting your transactions, you might have been commit after each update. Also, the standard disk cache is 2MB, so if you think your DB should have more memory than that, up it with default_cache_size.

Ah, I wasn't, so that combined with pilif's comments regarding the file being locked for writes would make a lot of sense as to why things were slowing down.

Thanks for the info.

Re: "SQLite is not designed to replace Oracle. It is designed to replace fopen()."

#57

Post by rbranson »

owenmarshall wrote: post #5
rbranson wrote: post #3

... because the only use for file I/O in applications is structured tables of data? What about audio/video, documents, graphs, log-structured data, object caches, unstructured flat files, etc? Don't get me wrong, SQLite is awesome, but this is a classic example of the relational database world's pervasive attitude that they are the superior solution for any data storage problem.

Wow. Not only did you manage to completely miss the point of that statement, but you cast it up as a hasty strawman to boot. I'm quite impressed. The choice of fopen() and Oracle was meant to convey simplicity: SQLite solves problems on the simple end of the difficulty spectrum -- problems you would normally solve with fopen(). It is not for problems at the complex end, like Oracle. It's a simplified expression; read…

Damn, you are so right bro.
Post reply on HN