7 ms·
The idea's not fundamentally bad, but some of the rhetoric raises alarm bells. > built atop SQLite, the fastest, most reliable, and most widely distributed dat
by notacoward 10y ago
The idea's not fundamentally bad, but some of the rhetoric raises alarm bells.
> built atop SQLite, the fastest, most reliable, and most widely distributed database in the world.
Most widely distributed maybe, but far from the fastest and AFAIK others beat it on reliability as well. No disrespect to SQLite, it's far more feature-rich than other embedded-style DBs, but without a definition of "database" that excludes them the statement as written is false.
> written for modern hardware with large SSD-backed RAID drives and generous RAM file caches
In other words, relies on those things so it won't work worth crap on anything less.
> The easiest way to talk with Bedrock is using netcat as follows
Nice security model you've got there.
- quinthar 10y agoRe: SQLite's performance -- Can you point to anything that shows SQLite isn't the fastest for some class of query? In my experience (though admittedly I haven't formally benchmarked) it's at least as fast, and generally faster (due to the dramatically reduced overhead to query it over a traditional database server). Re: SQLite reliability. I'm confused how SQLite isn't more reliable than every other contender, merely given that there is so much less to fail. In 8 years, 2158341079 writes, and probably 100x that many reads, I don't think I've ever had a single failure or bug with SQLite itself. Re: SSDs -- That's a fair point. Bedrock is not the ideal choice if you are using small volumes and spinning disks. Re: Security -- I think all databases have crap security that nobody really relies upon. Bedrock doesn't try to pretend. Rather, it gives you a very complete plugin framework, such that you can write C++ "stored procedures" that enforce your application's security model. In practice, we run with the Bedrock::DB plugin disabled, such that the only way to access the database is via our stored procedures -- and those do complete authentication and authorization in an application-specific way that no database could in a generalized fashion. Thanks for asking!
- ngrilly 10y ago> 2158341079 writes I'm curious: how do you keep track of this number?
- quinthar 10y agoEvery write transaction ever committed to the database is assigned a unique ID, and the most recent few million transactions are kept in a "journal" table. This is what allows nodes to figure out what happened while they were offline and re-execute the missing transactions. A side-effect of that is we know exactly how many write transactions have ever been committed.
- ngrilly 10y agoThat's a funny side-effect! Should I understand the transaction unique ID is an incrementing number?
- quinthar 10y agoCorrect!
- ngrilly 10y agoThanks :-)
- justinclift 10y agoOut of curiosity, what's the value that'll wrap around at?