It doesn't sound like a lot if it is processed linearly. However, 10,000 reader/writers on a single shared resource is a lot.

Naive implementations would have a single global lock on the resource, resulting in lots of contention. They appear to be saying that by converting to callbacks, they are able to determine which transactions will interfere with each other and limit the contention to just those portions. Deadlock would be a serious possibility here, same as in regular databases.

The size of the data is largely unimportant for this problem, it's the contention that's the issue.

If the spaceships didn't have to interact through the global state then you could have sharding. You can change the problem by adding "planetary systems", and saying that ships in one system can't interact with another. Instant shard.

Right. That's the whole point: shards are a solution that imposes constraints on the application, meaning it's not really a solution.

Also, SpaceBase guarantees no deadlocks.

According to the documentation, it does this by preventing callbacks from initiating transactions on the same SpaceBase store?

:) :) :) Isn't that a constraint on the application? :) :) :)

I think I'm going to have to look at the demo and see how a shot which triggers an explosion then does the query to perform the push of the surrounding ships.

I would expect something like:

  Ship A:
     Query(origin+direction+range, callback Shot())

  Shot()
     if Exploding
       Delete
       Query(origin, range, callback Boom())

  Boom()
     Update location

Except that's not allowed?

An AOE which causes cascades of death would be cool to see too.

Nifty idea.

I guess we must have missed all the places in the documentation where this is mentioned. As you see in the code, this limitation is no longer in place.

The real-world case for this is EVE Online, which has a fair amount of trouble handling 10K spaceships in a single battle. If I'm ever working on an MMO again I'm going to want to take a hard look at this tech. Some MMOs wouldn't benefit from it; on the other hand, I'd like to have the ability to do so rather than artificially constraining my game design space.

The data per ship in EVE is far more than the couple of data points in this simulation.

I once wrote a ship builder and simulator for EVE and man there's a lot of variables to take into account: the ship, the pilot, modules, implants, boosters, etc.

Still, like you said, very interesting technology and hopefully helpful to CCP!

Yeah, this wouldn't handle the whole battle, but even just off-loading the positional information would be huge.

First, consider the numbers: 20K ships * 5 times a second * (1 query + 1 transaction) = 100K queries + 100K transactions per second (each query returns about 5 neighboring ships). And the point isn't sheer speed, but scalability. The point isn't running the simulation as fast as possible, but demonstrating the database's capabilities.

But it's also a valid point; it's important to know if it scales well for larger datasets. I think the premise is good, we need better tools for creating multithreaded, concurrent applications. Looking forward to your future posts.