5 ms·

Really? I thought SQLite is for development purpose only. but 1000posts/day? Wow..

eksith 13y ago
I should add, that we ran nothing else on the box. Just the forum and it was text only (no image uploads etc...). Backups were pretty easy. ;)
corresation 13y ago
Please clarify "for development purpose only"? SQLite is used in a lot of production software you rely upon daily, and is one of the most robust, useful pieces of code going. http://www.sqlite.org/famous.html http://www.sqlite.org/famous.html Now it's an embedded database, which is why leokun's comment is out of place. However you can absolutely drop a queue in front of it, for instance, and serve many "simultaneous" users for a purpose such as a web forum.
onedognight 13y ago
> but 1000posts/day? Wow.. While a forum that gets 1000 posts/day is quite active, a database that does an INSERT ever 80s is not even moving.
- eurleif 13y ago
  Presumably there were many SELECTs for every INSERT.
  - eksith 13y ago
    Yes. Yes there were. :) We always limited transactions for UPDATES and INSERTs that involved more than one table. It was quite the learning experience since you do have to think of different ways of working with data. You get to learn very quickly the difference between what like to store vs. what you actually need to store to get a particular functionality. But that turned to being a boon in the end because we got a much simpler forum as a result. Fewer bells and whistles meant users focused on actual discussion and not ancillary, shiny bits and bobs.
  - vidarh 13y ago
    But on a machine with 2GB of RAM running a forum that small, pretty much none of those selects should ever need to hit disk - it should all pretty much be in the buffer cache, unless there were lots of full text searches of the entire posting history. EDIT: And that is without any app specific caching.
- vidarh 13y ago
  For comparison, 8 years ago I wrote a queuing system that did either in-memory queues, or wrote to sqlite for durability. With a little bit of tuning, the Sqlite queues could handle at the very least hundreds of thousands of messages a day - we never pushed it to it's limit.
Groxx 13y ago
Put simply, you thought wrong. SQLite is one of the most-used pieces of software out there, absolutely including production software. http://www.sqlite.org/mostdeployed.html http://www.sqlite.org/mostdeployed.html

I should add, that we ran nothing else on the box. Just the forum and it was text only (no image uploads etc...). Backups were pretty easy. ;)

corresation 13y ago

Please clarify "for development purpose only"? SQLite is used in a lot of production software you rely upon daily, and is one of the most robust, useful pieces of code going. http://www.sqlite.org/famous.html http://www.sqlite.org/famous.html Now it's an embedded database, which is why leokun's comment is out of place. However you can absolutely drop a queue in front of it, for instance, and serve many "simultaneous" users for a purpose such as a web forum.

onedognight 13y ago

> but 1000posts/day? Wow.. While a forum that gets 1000 posts/day is quite active, a database that does an INSERT ever 80s is not even moving.

eurleif 13y ago
Presumably there were many SELECTs for every INSERT.
- eksith 13y ago
  Yes. Yes there were. :) We always limited transactions for UPDATES and INSERTs that involved more than one table. It was quite the learning experience since you do have to think of different ways of working with data. You get to learn very quickly the difference between what like to store vs. what you actually need to store to get a particular functionality. But that turned to being a boon in the end because we got a much simpler forum as a result. Fewer bells and whistles meant users focused on actual discussion and not ancillary, shiny bits and bobs.
- vidarh 13y ago
  But on a machine with 2GB of RAM running a forum that small, pretty much none of those selects should ever need to hit disk - it should all pretty much be in the buffer cache, unless there were lots of full text searches of the entire posting history. EDIT: And that is without any app specific caching.
vidarh 13y ago
For comparison, 8 years ago I wrote a queuing system that did either in-memory queues, or wrote to sqlite for durability. With a little bit of tuning, the Sqlite queues could handle at the very least hundreds of thousands of messages a day - we never pushed it to it's limit.

Groxx 13y ago

Put simply, you thought wrong. SQLite is one of the most-used pieces of software out there, absolutely including production software. http://www.sqlite.org/mostdeployed.html http://www.sqlite.org/mostdeployed.html