Stand-alone in world data storage

[Avalon Criss]

I was looking for a stand alone in world system to save all the vending informations, but I've not found something that work in this way.  Every system available around, require an hosting off world to make some basic features working, like the redelivery of purchase made at in world stores (avoiding annoing manual update, of course).  Is there a particular reason, for the sellers, to prefer external server for manage the vending feature, instead saving all data in world?

 

[Rolig Loon]

Storage space. The maximum internal memory for a LSL script (Mono) is 64K.  That's enough for doing many things in SL but not for jobs that require storing large databases, especially if they have to manipulate or even search those databases in real time.  It doesn't many customer records to overwhelm a system that's relying on local storage.  So people move it off world or, if they have access, to KVP in an Experience,.  The recent addition of Linkset Data (LSD) has helped a bit, but it's still faster to handle large database operations externally.

Edited April 9, 2023 by Rolig Loon
typos. as always.

[Avalon Criss]

Yes, but for recording a purchase is enough 100-150 Byte (timestamp, buyer, object name, amount and location) and 64KB available in any prim can store about 500 records.  Doesn't seem a very large database required for this task, at least not as an ecommerce shop

[Love Zhaoying]

3 minutes ago, Avalon Criss said:

64KB available in any prim

Very soon to be 128k.

[Rolig Loon]

11 minutes ago, Avalon Criss said:

Yes, but for recording a purchase is enough 100-150 Byte (timestamp, buyer, object name, amount and location) and 64KB available in any prim can store about 500 records.  Doesn't seem a very large database required for this task, at least not as an ecommerce shop

Yes, I operated a single shop in world for a few years, using a system like that.  It works for that scale of operation. Larger stores, though, want to track a customer's purchases over time, offer redeliveries and special event opportunities, send updated versions, monitor the popularity of each item (color, size, style) to help plan for future products, and do all manner of statistical studies to figure out how to market better and how to build and maintain a growing customer base.  You can't do that with a bunch of unrelated scripts in prims in a single shop. The large systems like Casper that can do those things have become very popular.  They relieve store owners of a lot of the mechanical challenges of gathering and sorting databases and give them analyses at the click of a button, and they keep customers happy by making reliable delivery and money management the norm.  

[Quistess Alpha]

16 minutes ago, Avalon Criss said:

Yes, but for recording a purchase is enough 100-150 Byte (timestamp, buyer, object name, amount and location) and 64KB available in any prim can store about 500 records.  Doesn't seem a very large database required for this task, at least not as an ecommerce shop

not very much memory, no. you could easily fit it within the constraints of say experience KVP, perhaps even a few different stores sharing the same experience. Problem is the architecture, sure you cna store the data, but the tools we have for in-world only don't make getting it back out again convenient. KVP lets you index by exactly one key, and the size of data per key is finite (you can easily work around that by adding related keys, but it's a pain.) so, you could index by say the buyer, but then it would be very hard to re-sort everything by purchase date. External-to-SL databases are built to solve that kind of problem already, it's easier not to reinvent the wheel.

[Avalon Criss]

7 minutes ago, Quistess Alpha said:

you could index by say the buyer, but then it would be very hard to re-sort everything by purchase date

To sort by date, the keys name should include llGetUnixTime() at first, and then buyer id, obj name and shop name, to easily recall them by a findkeys search. It can be used for redelivery function after record check.

40 minutes ago, Rolig Loon said:

They relieve store owners of a lot of the mechanical challenges of gathering and sorting databases and give them analyses

Yes, however these are optional services added to the basic functions that someone needs

[Rolig Loon]

10 minutes ago, Avalon Criss said:

Yes, however these are optional services added to the basic functions that someone needs

Of course they are, but you asked

2 hours ago, Avalon Criss said:

Is there a particular reason, for the sellers, to prefer external server for manage the vending feature, instead saving all data in world?

so I told you.   Those may be "optional features", but they are very important features for merchants who operate with more than one in-world shop. Scripters have been making basic vendors for 20 years, so there are hundreds of variations on that theme.  Those are all largely ignored by the merchants who are making the big sales in SL.

[Quistess Alpha]

35 minutes ago, Avalon Criss said:

to easily recall them by a findkeys search.

experience KVP doesn't have findkeys. and managing LSD is A) new, B) wildly innefficient and cumbersome to manage across multiple linksets.

[Rolig Loon]

1 minute ago, Quistess Alpha said:

KVP doesn't have findkeys

You can script a key search in KVP but it is very slow -- essentially a looped list search -- and not something you'd want to do while a customer is waiting impatiently for a redelivery.

[Avalon Criss]

35 minutes ago, Quistess Alpha said:

LSD is A) new, B) wildly innefficient and cumbersome to manage across multiple linksets.

Why? Using brakelink and relink, a set of prims can be handled like sectors for the write. And for reading is even possible llSay between sectors and transmitter. The requests made by customers can be queued by more reliable llEmail that also prevent overlap, I think

[Quistess Alpha]

5 minutes ago, Avalon Criss said:

brakelink and relink,

llCreateLink has a 1 second built-in delay. llEmail has a notorious 20 second delay and has been reported to break until a region restart every now and again. I'm not saying it can't be done, it's just not a scaleable solution.

[Avalon Criss]

The delay of 20 sec is a minor issue.

32 minutes ago, Quistess Alpha said:

been reported to break

I know after restart nothing change in uuid of the prims, so the address will remain the same.

Do you mean the message queued during the restart will not be delivered?

[Quistess Alpha]

2 minutes ago, Avalon Criss said:

Do you mean the message queued during the restart will not be delivered?

Supposedly, once in a blue moon, email scripts just stop receiving all new emails until a region is restarted.

[Wulfie Reanimator]

If the sim is down, your server is down. If the server needs to be re-rezzed, other objects in other sims won't be able to find the new object.

I guess if you have all your stuff in one sim, that's not as much of an issue. But as a customer I wouldn't like having to find your store to get a redelivery... if your store still even exists by the time I want one.

Edited April 10, 2023 by Wulfie Reanimator

[Coffee Pancake]

16 hours ago, Quistess Alpha said:

experience KVP doesn't have findkeys. and managing LSD is A) new, B) wildly innefficient and cumbersome to manage across multiple linksets.

First person to write a PrimFS !

[Avalon Criss]

Region restart,  avoid change uuids (or keep open communications), simplify the request of redelivery, yes, are problems, but can be solved easily with related measures.

The marketing ware functions are intresting and surely offer add value to the tool, overall if there is integration build-in the products, that allow you make analysis and trend graphics as told Rolig Loon.

Coffee yes. PrimFS is the -only one- obj I found at MP for storage data in world, but it "rest" in the rudimental things. It seems not developed and like as presented, is usable only by programmers that are still capable to made it for theirself.  For this reason I asked the firs question