Is there a better NoSQL db?

>using any nosql stuff besides tdbengine 17 years ago
kys

File: redis.png (33KB, 1270x806px) Image search: [Google]

33KB, 1270x806px

Redis

>>58593359
But the chart doesn't include mongo

>>58593271
>MongrelDB
>database that loses its data
kys you motherfucking retard.

>>58593271

What kind of toy application are you writing where you don't need referential integrity?

>>58593359
>Redis is the fastest
>in a comparison to a handful of cherry-picked slow nosqls
>according to redis

MongoDB
>No consistency
>No partitioning
>No transactions
>No permissions
>No security
Why do people use this DB
>B/c you can change your data model on the fly
>It is so fast!
So it's only good if I build something without understanding how it'll work when I'm finished(?)

>>58593271
>Is there a better CrippleStorage/MorbidMemory?
Literally everything else.

>>58593440
>>58593383
mongoldb didn't even make the list.
sorry babbies :(

>>58593271
NoSQL is in itself retarded in the way most people do it.
Just learn to use a proper database system.

>>58593451
people use mongo for fast writes and for when the data has irritatingly complex schemas and it's ok if you don't get all of it. My friend used it in the past for doing real-time analysis of twitter data (he's a data scientist)

not the standard anymore by any stretch. but it made sense one time

>>58593432
When dataset isn't necessarily correlated.

>>58593503
Do you know what he switched to?

>>58593513

You can still use a decent database for those use cases, plus when you finally figure out that there are some correlations (not if) you don't have to replace your database.

>>58593503
It's also something you would want only if missing one in a million records doesn't matter - same with using an elastic backend.

If you're making generalizations about the data being collected, and you need that data to be relatively permanent, and you will never need to ask questions about the data that brings up a relationship with other data you're working with (Mongo's "joins" are fucking shit tier), then MongoDB is fine.

I certainly can't think of a good reason to use Mongo though, because I can't think of any system with that use case.

>>58593601
Yeah, just entire schema.

>>58593602
Can you think of a light db to run on resource constrained embedded device? I need something to facilitate persistence layer for 2 applications that will run in parallel on said embedded device. One does reads+writes and the other would just read the data.
It's meant to store settings/config so I would be more than happy to sacrifice performance for low footprint.

>>58593808

If you're doing embedded chances are you're going to have to roll your own db.
Its pretty easy to write one in Forth which runs in a ton of small devices.

>>58593397
If that's what they need to do to get those kickass benchmarks, then it's a great design.

>>58593271
All of them.

>>58593808
Is there a reason you couldn't just use a JSON or XML or your own proprietary kind of flat file for this? Have a backup "default settings" file that can be generated in case their settings fuck up?

A "read config" sounds like it happens at startup and is kept in the program until restart. Is that the case, or would you need to constantly access the file to read out settings?

NoSQL is a meaningless buzzword grouping unrelated technologies (which often do in fact use SQL as a query language).

The original question is dumb.

File: 1471484743258.jpg (42KB, 666x1000px) Image search: [Google]

42KB, 666x1000px

>>58594483
>If that's what they need to do to get those kickass benchmarks, then it's a great design.
You might as well store to /dev/null then.

>>58593271
>NoSQL db
Why would you do this?

>>58593271
Postgres storing JSON as binary blobs
Will still be faster kek

>>58593271
Everyone who is using this MongoDB shit needs to watch this:

https://www.youtube.com/watch?v=b2F-DItXtZs

Nothing has changed since then. MongoDB is still total pile of shit. It's only popular because there's lots of tutorials about it and retards find it easy to use.

>>58593271

PostgreSQL.

Not even kidding, it has support for JSON these days.

File: lmao.png (229KB, 375x376px) Image search: [Google]

229KB, 375x376px

>>58594670
>I think you mean impedance

couchdb

all json-based databases are complete shit

>>58593440
not to mention they accomplish this by making no guarantees about your data randomly disappearing

>>58594803
muh Elasticsearch

>>58593271
>NoSQL
I'm so glad this meme is dead and never made it into the enterprise.
Only exception that comes to mind is graph data. Graph DBs are the only NoSQL that I've used that I feel like is actually useful.

>>58593808
sqlite is especially fitting if only one process is going to write.
sqlite also has one of the easiest to use FTS indexing I've ever used.

>>58594874
>Elasticsearch as an application DB
I had a colleague on my project suggest that we do this.
Like wtf is wrong with people? ElasticSearch is great, but why the fuck would you use it as a database?
Thankfully the lead was sane and quickly shut that idea down.

File: 178379823724.png (180KB, 482x322px) Image search: [Google]

180KB, 482x322px

>mongo

RethinkDB

But it died because VCs pulled funding.

>>58593808
used sqlite in a similar setting once and it was pretty easy to use

https://cassandra.apache.org/ is good but, personally I'm using redis for smaller projects.

why are people so afraid of relational databases?

>>58593359
Different use cases alltogether

>>58599734
Sharding postgreSQL is a pain in the ass.

>>58599734
Joins are slow as fuck.

>>58594698
It's also faster in benchmarks when dealing with that JSON data.

It got so silly that MongoDB actually uses PostgreSQL underneath for some features: https://www.linkedin.com/pulse/mongodb-32-now-powered-postgresql-john-de-goes

>>58593271
No.

>>58593359
Redis is key-value not noSQL

I want to learn about databases and I plan to take a course on SQL, what's the point of using MongoDB over SQL?

>>58594528
Application reading the config would do so periodically during runtime (ultimately as soon as settings are updated via some kind of hook or event) so going with flat JSON would probably force me to write a layer to deal somehow with file locking prior to reading and writing

>>58593271
>using software that has "mongoloid" in its title
>nothanks.jpg

>>58593271
mongo is the php of nosql databases.

use something non-retarded like cassandra

>>58593359
now turn on the fsync-on-every-write option in redis to make it as durable as other nosql and watch the performance plummet

>>58603352
Please use the right tool for the right job.

Its not at all about what sounds fun or is a meme, its about what works the best for the given problem.

999/1000 it will not be the language or tool what holds you down, but your own choices and architecture.

Hbase is 10/10

>>58603402
>storing your database every few seconds
with this aptitude for software design no wonder they are shit
>>58602167
you can store hashes and things, it can do everything mongoldb does, much faster
>>58599777
wrong