They mention using Neo4j instead of a relational database. Recently I needed to implement a friendship data model, and started off using Neo4j because it seemed like the best tool for the task, but ended up using essentially the following model in Postgres:<p><pre><code> CREATE TABLE friendship (
person1 INT NOT NULL,
person2 INT NOT NULL,
PRIMARY KEY (person1, person2),
CHECK (person1 < person2)
);
CREATE INDEX friendship_person2 ON friendship(person2);
CREATE VIEW friendship_view AS
SELECT person1 AS person, person2 AS friend
FROM friendship
UNION
SELECT person2 AS person, person1 AS friend FORM friendship;
</code></pre>
taken from here: <a href="http://www.postgresql.org/message-id/20141111201127.d80b6bc4c2a6970a6b941dec@potentialtech.com" rel="nofollow">http://www.postgresql.org/message-id/20141111201127.d80b6bc4...</a><p>What do you folks think? It seems like this would be the densest way to store the relationship, using the checked constraint trick with the IDs so you don't need duplicate records to store Alice and Bob's friendship as {A -> B, B -> A} if the friendship is inherently bidirectional (vs a followed/follower model), and doesn't preclude one from storing the data in another isomorphic structure that might be optimized for specific queries. I'm sure it's possible to replicate this with Neo4j, but it felt cumbersome programming that in Java versus expressing that in SQL. But I'd really like to use Neo4j in an OLTP environment, but still haven't had enough of an impetus yet because WITH RECURSIVE in postgres works well if the recursion depth is capped.
Worst-case, you'd have to process input at a sustained rate of (140×250×1000000)/(24×3600) = 405093 B/s.<p>I certainly hope your system can manage 400kBps throughput.