Entries by Guy Harrison
(96)

Squarespace has been a great platform, but it seems to me that medium.com has really created a network effect for blogging that overwhelms all the downsides of having to write within someone else's platform. So going forward I'll be blogging at medium at https://medium.com/@guy.harrison.

I've been running this blog on squarespace for about 7 years and for a few years before that on typepad. If you check out http://guyharrison.typepad.com/ you can see how young and beardless I was in those days! :-)

All my older material will remain on Squarespace, though where there is an updated medium article I will link to it. Mostly my new blog content is around blockchain and MongoDB technologies (at least for now). Oracle and MySQL stuff will remain here. It was next to impossible to migrate Squarespace in bulk to medium.

Please checkout my medium page if you've enjoyed the content here - also my little startup dbKoda has it's medium account at https://medium.com/dbkoda. You'll particularly like that if you are interested in MongoDB.

Most of my recent blogging has been done on the dbKoda website where I've been writing mostly about MongoDB performance tuning. If you are interested, here are links to a few of the more interesting posts:

An index is a object with its own unique storage that provides a fast access path into a collection. Indexes exist primarily to enhance performance, so understanding and using indexes effectively is therefore of paramount importance when optimizing MongoDB performance.

As human beings, we get used to the limitations of the technologies we use and over time forget how fundamental some of these limitations are.

As a database administrator in the early 1990s, I remember the shock I felt when I realized that the contents of the database files were plain text; I’d just assumed they were encrypted and could only be modified by the database engine acting on behalf of a validated user. But I got used to it.

I also got used to the idea that the contents of a database where pretty much what I – the DBA – said it was. Rudimentary audit logs could be put in place to track activity, but as DBA I could easily disable the audit logs and tamper with any database if I so desired.

I think it’s obvious to all of us that this is not the way it should be – contents of production databases should be trustworthy, We should know that a DBA, hacker or privileged user has not tampered with the contents of the database. However, until recently we lacked the technology to ensure this.

The emergence of a tamper-proof distributed ledger in the form of the Blockchain now promises to give us a mechanism to at least “seal” database records. We can’t necessarily stop a hacker or malicious insider from breaking the seal, but we can at least know if the seal has been broken.

In this post, I’ll show how to implement a simple Blockchain seal for MongoDB. We’ll record a hash value corresponding to a set of documents in a database. As long as the hash value has not changed, we can be confident that the database records have not been tampered with. The hash value is stored on the Blockchain so that we can know with certainty that a particular hash value was in effect at a specific point in time.