3 ms·

Are use case driven DBs helpful? Is the use case and possible adoption crowd large enough to sustain a product this critical down the road? I worry about the p

Are use case driven DBs helpful? Is the use case and possible adoption crowd large enough to sustain a product this critical down the road? I worry about the proliferation of infra level tools or adopting a new one. Why not make an extension or fork postgres to demonstrate your concept? (Just an example)

unchurched 7y ago
Timeseries databases have an entirely different set of technical challenges from relational databases. Also, I wouldn’t exactly call this proliferation. There are relatively few decent timeseries databases in existence, some of which have been around since 1999. So yes, timeseries databases are incredibly helpful if you have to store, well, large amounts of timeseries data quickly.
cat199 7y ago
> large enough to sustain a product this critical down the road? This may not be a 'product' per se. also, these libraries tend to be small and self contained and little changing over time. See also: https://svnweb.freebsd.org/base/release/12.0.0/lib/libc/db/changelog?revision=341707&view=markup https://svnweb.freebsd.org/base/release/12.0.0/lib/libc/db/c... for a view into the original berkeley db as still incorporated in freebsd base (BSD Berkeley DB v1; not the later lineage by same authors which led to sleepycat / oracle Berkeley DB). > Why not make an extension or fork postgres to demonstrate your concept? this isn't that kind of database. this is a k/v store optimized around a particular use case, k/v stores being what is more traditionally considered 'database' before the term 'database' colloquially implied 'relational database managment system' (RDBMS - e.g. a system to manage your k/v database files relationally..) well, techincally 'database' is any 'base of data'. but.. yes. 'base of data' -> 'k/v store' -> 'rdbms' See also: isam,dbm,bdb,cdb,gdbm,tdb,tokyo cabinet,kyoto cabinet,etc. concievably, if desired, one would take this library and integrate it into a higher level application, whether that be a custom application datastore, or a new backend for something like postgres.

unchurched 7y ago

Timeseries databases have an entirely different set of technical challenges from relational databases. Also, I wouldn’t exactly call this proliferation. There are relatively few decent timeseries databases in existence, some of which have been around since 1999. So yes, timeseries databases are incredibly helpful if you have to store, well, large amounts of timeseries data quickly.

cat199 7y ago

> large enough to sustain a product this critical down the road? This may not be a 'product' per se. also, these libraries tend to be small and self contained and little changing over time. See also: https://svnweb.freebsd.org/base/release/12.0.0/lib/libc/db/changelog?revision=341707&view=markup https://svnweb.freebsd.org/base/release/12.0.0/lib/libc/db/c... for a view into the original berkeley db as still incorporated in freebsd base (BSD Berkeley DB v1; not the later lineage by same authors which led to sleepycat / oracle Berkeley DB). > Why not make an extension or fork postgres to demonstrate your concept? this isn't that kind of database. this is a k/v store optimized around a particular use case, k/v stores being what is more traditionally considered 'database' before the term 'database' colloquially implied 'relational database managment system' (RDBMS - e.g. a system to manage your k/v database files relationally..) well, techincally 'database' is any 'base of data'. but.. yes. 'base of data' -> 'k/v store' -> 'rdbms' See also: isam,dbm,bdb,cdb,gdbm,tdb,tokyo cabinet,kyoto cabinet,etc. concievably, if desired, one would take this library and integrate it into a higher level application, whether that be a custom application datastore, or a new backend for something like postgres.