#OO

Can be done regardless.

Even MVC is an OO design pattern, first introduced by SmallTalk a pure OO language.

Unless we are talking about a language such as JavaScript, most languages support a tightly packed data structure. So doing something OO isn't going to impact on memory efficiency very much.

A few caveats emerge when you introduce flexibility like subclassing, mixins, and property bags.

#MVC

I don't think you have a tight grasp on what MVC actually is.

I think you are instead talking about Active Record sets, or similar technology where the database tables are themselves exposed as tables to your own functions.

Now it is possible to use an Active Record as the Object Model in an MVC implementation. In which case it is unfair to state that the code is less encapsulated.

• There was an active choice to work at the level of sets of things instead of with a thing.
• There was an active choice to use a data-agnostic and thus business logic anaemic representation.
• There was a choice to house the business logic externally. (Otherwise the active records themselves would have been wrapped by an object).

#How much memory?

• 1 byte for a Boolean
• 6 bytes for an IPv4 + Port (18 bytes for an IPv6 + Port)
• 16 bytes for a GUID
• 8 bytes for ticks at last check
• 8 bytes for polling delay (if each camera can be polled on a different cadence)

That gives you:

• 39 Bytes (48 Bytes Padded to 16Byte alignment) for an IPv4
• 51 Bytes (64 Bytes Padded to 16Byte alignment) for an IPv6

1Gb of memory (1024 * 1024 * 1024 bytes)

• 22,369,621 aligned IPv4 camera instances (27,531,841 unaligned instances)
• 16,777,216 aligned IPv6 camera instances (21,053,761 unaligned instances)

With a few tricks, it is possible to squeeze this even further down.

#Dilemma

But no matter what you do this data will exist somewhere, be it stored in the database, or in the program itself.

Note that if a program asks for more memory than can be stored in RAM, it will be paged to the disk, exactly like it would happen in a database.

A Modern computer with access to even 2GB of ram, and an SSD is more than capable of marshalling the 6GB of Memory space required for your 100,000,000 instances, because the addressable space in most 64bit applications is currently around 2^40. Well in excess of the range before you need to worry about manually swapping data out of the process to free space for further work.

If that appears to be too slow, the cheapest way to actually improve performance would be to upgrade the servers ram. 16GB is not that expensive these days, and even 64GB is reasonably priced.

If for some reason your client, who can presumably afford 100 million cameras, cannot afford either several servers each working on a subset of the problem, or enough ram to house it all in one machine, then there is not much you can do.

#Database

What purpose does this database serve for you?

• Is it just a serialisation format, to just save all the data in your program to, and then load it up again?

• Is it an integral part of the algorithms and processes that your are implementing providing data crunching, memory management, and multiple concurrent access?

OO

Can be done regardless.

Even MVC is an OO design pattern, first introduced by SmallTalk a pure OO language.

Unless we are talking about a language such as JavaScript, most languages support a tightly packed data structure. So doing something OO isn't going to impact on memory efficiency very much.

A few caveats emerge when you introduce flexibility like subclassing, mixins, and property bags.

MVC

I don't think you have a tight grasp on what MVC actually is.

I think you are instead talking about Active Record sets, or similar technology where the database tables are themselves exposed as tables to your own functions.

Now it is possible to use an Active Record as the Object Model in an MVC implementation. In which case it is unfair to state that the code is less encapsulated.

• There was an active choice to work at the level of sets of things instead of with a thing.
• There was an active choice to use a data-agnostic and thus business logic anaemic representation.
• There was a choice to house the business logic externally. (Otherwise the active records themselves would have been wrapped by an object).

How much memory?

• 1 byte for a Boolean
• 6 bytes for an IPv4 + Port (18 bytes for an IPv6 + Port)
• 16 bytes for a GUID
• 8 bytes for ticks at last check
• 8 bytes for polling delay (if each camera can be polled on a different cadence)

That gives you:

• 39 Bytes (48 Bytes Padded to 16Byte alignment) for an IPv4
• 51 Bytes (64 Bytes Padded to 16Byte alignment) for an IPv6

1Gb of memory (1024 * 1024 * 1024 bytes)

• 22,369,621 aligned IPv4 camera instances (27,531,841 unaligned instances)
• 16,777,216 aligned IPv6 camera instances (21,053,761 unaligned instances)

With a few tricks, it is possible to squeeze this even further down.

Dilemma

But no matter what you do this data will exist somewhere, be it stored in the database, or in the program itself.

Note that if a program asks for more memory than can be stored in RAM, it will be paged to the disk, exactly like it would happen in a database.

A Modern computer with access to even 2GB of ram, and an SSD is more than capable of marshalling the 6GB of Memory space required for your 100,000,000 instances, because the addressable space in most 64bit applications is currently around 2^40. Well in excess of the range before you need to worry about manually swapping data out of the process to free space for further work.

If that appears to be too slow, the cheapest way to actually improve performance would be to upgrade the servers ram. 16GB is not that expensive these days, and even 64GB is reasonably priced.

If for some reason your client, who can presumably afford 100 million cameras, cannot afford either several servers each working on a subset of the problem, or enough ram to house it all in one machine, then there is not much you can do.

Database

What purpose does this database serve for you?

• Is it just a serialisation format, to just save all the data in your program to, and then load it up again?

• Is it an integral part of the algorithms and processes that your are implementing providing data crunching, memory management, and multiple concurrent access?