(it's "node-oriented", if that even exists)
Start here. When dealing with a complex application like a database (even a simple database is a complex application), you should be familiar with the history of the domain and the proper terminology and have at least a very high level idea of the architecture. You could start from the Wikipedia article on Database. Spent a few days reading all the articles on the related concepts and the different database types.
And since what I have in mind is neither relational nor document-oriented
Next, you pick Relational or NoSQl. If you pick NoSQL, you should pick one type of NoSQL. That's extremely important, you won't find any architectural documents that discuss all different database families. It doesn't really matter which one you pick, just pick one and stick with it.
The language does not matter in the slightest.
Yes it does (unfortunately), because after you pick a database family you should start exploring code from open source databases of that family. There are a few generic guidelines on what to look for:
- Relatively small codebase,
- Architectural documents or at least a development blog,
- The database you pick should be close to what's considered generic in the family, it'd be harder to learn from if it's highly specialised.
A few examples that fit:
Get the source, compile it and play around with it. You don't have to submit patches or anything that fancy, just explore the code and make small alterations here and there to see what happens. It's an incremental process, the more you play around with it the easier it'll be to understand what the code does. If the first project you picked seems extremely hard to understand, just move on to the next one.
Another great option would be to concentrate on building an engine for MySQL, as @N.B. suggests in an earlier answer.
If you do reach a point where you are able to do something useful with the codebase, get involved in the project's community, that's the easiest way to find more detailed resources on the concepts involved.
And then, finally, start working on your database. At first you could just write up an extremely scaled down clone of the code you've been exploring. It doesn't have to be original, quite a few great projects started out as clones or forks.
What resources/tutorials/books can I read to understand?
There are quite a few books:
And a few hundred others, plus a myriad of academic papers you could easily trace via Google. You need to define what you want to do first, and then search for a book. Getting involved with a community of fellow database authors will also help you narrow down the list of books and perhaps get a lot better suggestions than the above.
Good luck! I'm expecting a comment with a link to your repository when you're done. And if you're never done, make sure you leave a comment reminding me that I still haven't finished that compiler I started writing in 2001.
I studied open-source DBs, but their codebase is too huge: If something like redis or flockdb is too huge for you to read, I don't see how you'll cope writing or own database.