Hacker News Reader

Comment by AaronBBrown | Hacker News Reader

"CodernityDB pure python, NoSQL, fast database"

Is the fact that it is written in "pure Python" really the most important thing to reenforce after the name of the product itself?

Why would I use this over established products like Riak, Redis, MongoDB, etc?

View on HN

> Is the fact that it is written in "pure Python" really the most important thing to reenforce after the name of the product itself?

It's definitely a selling point for Python programmers, because it's so easy to use with your Python projects. You just set the package requirement and you're done, it will work in the same environment wherever your app works, upgrades are a piece of cake, no need to worry about platform support, permissions, etc.

f.ex. Whoosh (full-text search) gained a lot of traction in the Python world not because it was the fastest at the time nor the most full-featured (compared to the more mature Java-based ones), but because of convenience. Such solutions, even when they're not the most advanced player in the league, are great for starting up fast and pushing features out the door.

On a side note, it's a pleasure for me to see it's from Poland. Will test it out on a feature project in the next few days.

The thing I like most in python is not python itself but a "pythonic way". "Pythonic" > Python.

In my opinion, it's not "pythonic" to use DBMS, just because it written in python.

So the "selling point" is flawed.

Disclosure: I'm using python since 2006. I've made a lot of evangelizing it. It is my weapon of choice for many tasks. And I will never use python for many other tasks. (Don't tell me about PyPy or Stackless)

You make an excellent point, but when working in Python there are advantages to tying in to tools that are also written in Python. They will tend to be easier to integrate into your project than non-Python code[1] and more than that will generally be easier for you to extend or tweak[2] if you run into a case where you have to "look under the hoos" for some reason.[3]

[1] Python works well with other languages of course, and is often used as a "glue" between other components.

[2] This assumes that you know Python better than whatever language it was made in, but for many cases that will be true.

[3] I often like to look at libraries just to understand how they work, but that is different. There are often cases, especially where the tool uses some abstraction that can leak, where you need to look under the hood just to get things working.

I'm an architect in my firm and I'm tired of: a) .NET-ters who will use something only if it is .NET or at least Microsoft b) Javers who think that everything non-java is universal evil.

(We have 45% of .NET-ters, 35% of javers, 20% : devDBAs, Js-ers, others)

My propaganda is always: "Be programmers, mazafakerz!" And python is excellent tool for explaining ideas between this groups. Javer will not be offended if I show him .NET-code and otherwise.

For them python is "executable pseudo-code".

It will be sad for me if pythonistas became a caste like .NET, Java ... and Haskel (they are not a caste but have all possibilities to became one)

'a selling point' != 'just because'.

I get your point and I'm all in for being language-agnostic when it comes to the tools I have to use, but that doesn't change the fact that convenience plays a role when you are in a point where you can't affort a long-term decision process. the best technology to quickly launch something is most often simply the one you know.

If you look at the speed benchs they compare it to kyoto cabinet. I think that CodernityDB is meant to be embedded and is thus only interesting to python people. In that case the advantage would be to avoid the compilation step on intall that kyoto cabinet or sqlite would incur.

It's a library database like sqlite and kyoto cabinet

Looks like they also have an HTTP service and a Python client library, so you can use it other ways than embedded, and for the Python client, you can switch back and forth from the embedded one to the HTTP one with the same API. Seems pretty slick.

Python is on almost every host out there now. Riak, Redis, and MongoDB are not, and on many hosts you won't be able to compile them from the source. So yes, that's relevant.

If you are on a host without a compiler you don't need a NOSQL db.

How do you figure?

I believe the insinuation is that if you're actually building a serious app that might actually benefit from NoSQL, then you should host it on a serious machine and not some shared hosting solution.

Basically conflating the idea that NoSQL is for 'real projects' and that only 'amateur hour' hosts have no compiler.

NoSQL is targeted at extreme performance. So, yes, it sounds like a reasonable assumption.

There are other advantages to NoSQL, like flexible data structure, and not having to squish your data into two incompatible data models.

Wouldn't you want to remove extraneous software eg. a compiler from a dedicated database host for security? (Yes, Python could be included in that as well)

What platforms are people trying to run Riak, Redis, and MongoDB on where a package is not available, or a compiler is not available?

add repository.... {apt-get,yum,brew,port} install {mongodb,riak,redis}

I see little benefit in compiling any of these products from source.

Avoids dependency issues when you try to deploy your work on an unmodifiable target.

I've been looking at DBM::Deep (one of perl's equivalent to CodernityDB) and App::FatPacker recently just for this case (install a script on some Macs with only Perl being needed requirement).

ref: https://metacpan.org/module/DBM::Deep | https://metacpan.org/module/App::FatPacker

For me, the db being in pure-python means a db that can be easily extended or augmented. If you have some quirky requirement your options are 1) implement this in the client, or 2) modify your db. Option 1 is probably what most people opt for (how many people have the confidence to dig into postgres/mysql source, how many of these people want to?), and a pure-python db makes option 2 more feasible.

"Is the fact that it is written in "pure Python" really the most important thing"

It is for me. It's the most unique attribute about the project. Fast? Yawn. NoSQL? Yawn.

Although pure python seems great for some apps, for a piece of software I'd like to be highly optimized, it seems to hit the wrong sweet spot -- it means a larger memory footprint and less robust multi-threading than other pure language implementations. When things need to work fast and tight in python, most implementations duck down to C, like numpy and scipy. Or maybe I've been out of touch with improvements to CPython?

Threading in Python is totally capable here. A database is more likely I/O bound than CPU bound.

What about memory? There's a fairly large overhead for pure python data structures compared to C/C++.

perhaps it could be attracting devs, since python is a really awesome language to work with. but really, let's quit the snarkyness.

Reply on news.ycombinator.com