What exactly is the point of noSql

brainlet

>inside every NoSQL application is a an ad-hoc, informally-specified, bug-ridden, slow implementation of SQL
FAST implementation of SQL, GARANTED ACCELERATED WITH INDEX FILES

Devs love it because they don't have to think about the schema

Spark... NoSQL and SQL both converted to Java at the driver. So, it doesn't matter what language you write, it's all the same.

Just use flat files bro.

brainlet who don know what INDEX FILES is for

>operations that SQL isn't capable of.
ANSI SQL 99 is Turing complete you absolute retard.

So you can throw all your shit at it and it will all stick. So the point is it's a database for shit throwers.

Getting your fuckhuge, unfixed-grid tree structure object into some sort of meaningful storage mechanism without killing yourself.

Attached: 1417918696256.png (900x891, 148K)

>ANSI SQL 99 is Turing complete you absolute retard.
BrainFuck is Turing complete you absolute retard.

Sql is sexist, so we say no to sql.

>gets called retarded for saying NoSQL I is good for doing things a Turing complete language isn't capable of
>makes a retarded reply to show that he really indeed is retarded

I was investigating nosql options because it seems to fit my use case exactly but I never find anything usable. The best I had been made aware of before was arangodb but it was too tied to muh web interfaces and too niche to be easily usable in my language of choice except through a rest api of all things. Everything else was java, backed by a company reputed for making shitware, or closed source (or any combination of these). As a result I had no choice but to rely on sqlite, which is not that bad but kind of like fitting a round peg in a square hole. For example, I need efficient filtered random accesses, and there's no way to do that in an sql db. My test db is around 86GB so "order by RANDOM()" doesn't work, but I also don't want a contiguous slice so taking a random value in advance doesn't work. And generating random indices is not enough because they're not guaranteed to have the right properties to not be filtered.

It's good for rapid development, when you wanna just shove shit in a database and it will work, then you don't have to deal with migrations or anything.
You also need bare minimum database knowledge, with something like graphql you can boil it down entirely to just:

>insert data into front-end
>shove it in the DB
>when needing to get data out you just write a query that says what data to get on the front-end
>job done lol

I am starting to learn SQL. Are you telling me that there are people out there who can't understand it? I have picked it up pretty fast in just two days.

Check out scylladb, it's basically Cassandra but in c++. It also supports cql and is open source.

Thoughts on firebase firestore? I'm about to launch an app based on it and concerned about costs. Do most nosql services charge per read/write?

>C++
That's a deal breaker, if it doesn't have a C api it can't be wrapped.

Does ShitGoDB still not have transactions? How the fuck are you supposed to do multiple table queries without them? Do you wrap you db in a mutex or some shit and limit the number of connections to 1?

syntax is easy, querying big data efficiently not so much and that's the difference between junior devs and senior devs/DBAs

>>C++
>That's a deal breaker, if it doesn't have a C api it can't be wrapped.
Tell that to digia. Qt has practically bindings for every language.

what they are for?

Attached: 1549991728314.jpg (636x513, 73K)

Except it isn't hard? Even fucking sqlite3 has a built-in feature to emit an explanation of its query plan. What shitty SQL using DB doesn't have a similar feature?

Not doing one kind of data structure for all data. A data structure that also doesn't scale that well across servers.

Also, not doing crappy SQL language dialects with their own data types and conversions between that and your actual programming language when you're anyhow actually only interested in having a database for use by the latter.

I don't actually write code on sqlite, I only ever use enterprise server farms running oracle/DB2/teradata/microsoft clusters and I need to join data from hundreds of different data warehouses so sqlite generally doesn't fit the bill for that.

Just use Cassandra or maybe Spark [backed in something] from Scala or another JVM language.

Probably works nicely with 86GB of data and sufficient machines.

It uses binding generators which are a dogshit hack at best and don't work in the general case.

>(((jvm)))
>(((scala)))
>(((spark)))
>(((cassandra)))
"No".

So the ecosystems that tend to work best for this by far are just too simple for you?

Enjoy doing your big(-ish, would not actually push a glorious Java stacks that much) data tasks directly on fickle & slow sqlite then.

Attached: 55364f17caec6e49a6e4bd8b7166125e.png (1584x1584, 2.31M)

>(((best)))
>leaks memory all the time
>bugs out the ass throughout the ecosystem
>take years to do an hour's worth of work
>crap to do anything non-trivial with
>endless gc pauses
>slowest edit-test-debug cycle known to man
>unusable without an IDE that doesn't run on less than 320TB of ram
OK kid

How does this thread not constitute as spam?

None of these maymay issues. At most the compiles are medium slow, but on the usual fancy cached compile build environment you won't even necessarily notice much.

And even if it'd be as bad as some unemployed Rust rantfag may claim, it'd be better to put up with it to ultimately have a fast flexible application than run sqlite's slow hangup galore. So sayeth also just about all of the actual production big data.

Attached: keynotes.jpg (3925x1696, 537K)

>ai
>spark
Choose precisely one
>javatards
>anything more than clueless pajeets
Thanks for proving it can be only one.

Use elixir/erlang instead.
BTFOs everything else.
Literally no compromises.

Dead set on using something that doesn't work rather than the open sauce stacks that currently does much of the actual big data (and yes, also the AI / machine learning people) work with, eh?

Well, you're not doing too great, meanwhile many of them are clearly processing data sets a thousand times larger in more complex ways and are doing fine.
They can even throw fucking CSV files at Spark and with halfway adequate code and processing power it'll randomize and filter them faster than your SQLite, and the whole thing is also programmed faster.

But hey, make up imaginary problems why it clearly all can't work on their end - it *IS* the only way you could reach approximate parity with what you have right now.

Attached: smug.png (600x665, 479K)

Erlang was a huge inspiration for the JVM ecosystem. But in terms of how long Erlang has been around vs. how many managed to use Erlang code in production, it really didn't work out all that well.

Then Akka, Spark, Cassandra and friends showed up and they just solved long existing performance problems all over the place, usually within days to months. Maybe it's just because people are better with Java than Erlang, but this probably applies also for user. And that part of JVM ecosystem additionally exploded with its huge success, it is now much larger than Erlang/Elixir's.

It BTFO'd Erlang and everything else.

But you're right otherwise; I'm also rather sure Elixir/Erlang would work okay enough.

What language are you using?

Well if you want a solution to huge scale concurrent problems, erlang or go are your only realistic choices. From every benchmark I've seen Play has around 3x as much latency as both go and elixir/erlang, and has terrible consistency of that latency also.

Obviously any solution is probably good enough in reality because the end user probably won't notice 1ms vs 20ms anyway, but still.

> if you want a solution to huge scale concurrent problems, erlang or go are your only realistic choices.
The JVM is used far more for that, it runs the heavy lifting in CERN, Twitter, Netflix and many more. Yes, real huge concurrent problems.

Certainly, Google has its own NIH toys and I'm sure if we had their actual stack, it'd be pretty popular. But Google isn't providing these with Go. They're providing Go.

>Play
Play is a large *web framework*. Still pretty fast and easy to use in its problem domain, but ultimately not even what you'd use for big very fast websites on Java/Scala, or to do distributed fast computations/data storage and retrieval.

When all you want is global thread safe data structures it makes more sense to use noSQL than serializing and deserializing complex data structures as strings, using an ORM, trying to manually represent your data as rows, or trying to use the file system. All you wanted was your web server to send messages to a queue, but now you want to use a production server and you've gained weird limitations.