Re: Managing a graph with large number of nodes

You might use a disk based hash, DBM::Deep. Seems to me your best option without knowing any more details

Or an SQL database (lots of database interfaces around, for example DBIx::Simple, DBIx:Class), but you also would need to install a database engine.

Files for individual nodes would be a bad idea, as every access of a node would entail the opening of a file, heavy overhead I would assume.

Comment on Re: Managing a graph with large number of nodes

Replies are listed 'Best First'.
Re^2: Managing a graph with large number of nodes by Jenda (Abbot) on Nov 02, 2009 at 08:49 UTC
Installing a database engine is not such a problem. There are quite a few to choose from. Even most of the big expensive ones have free developer versions. Plus you may use DBD::SQLite which is a database engine inside a module. No need to install anything more. Jenda Enoch was right! Enjoy the last years of Rome.	[reply]
Re^2: Managing a graph with large number of nodes by dsheroh (Monsignor) on Nov 02, 2009 at 11:37 UTC
Depending on the nature of the nodes and how they're going to be accessed/manipulated, an object store (such as Pixie, Tangram, or KiokuDB) seems likely to work well for something like this, while avoiding the need to worry about SQL schemas (even if the objects are ultimately stored into an SQL database).	[reply]
Re^3: Managing a graph with large number of nodes by Jenda (Abbot) on Nov 02, 2009 at 16:49 UTC
Well, in this case it seems that the whole schema will be just two tables `CREATE TABLE dbo.Users ( Id int not null identity(1,1) primary key, Code varchar(...), FirstAttribute ..., SecondAttribute ..., ... )go CREATE INDEX idx_Users_Code ON dbo.Users(Code) go CREATE TABLE dbo.Links ( UserId1 int not null, UserId2 int not null, Weight ..., CONSTRAINT pk_Links PRIMARY KEY CLUSTERED (UserId1, UserId2) )go` [download] and that's about it. Object store is most likely an overcomplication in this case. Jenda Enoch was right! Enjoy the last years of Rome.	[reply] [d/l]