[3537]

Hundreds of thousands of documents per day

Date:
February, 2011
Prototype:
proto$ gen V mod 2A15A6 (Londinium)
Customer:
Ulmart
are created within dia$par by Ulmart personnel. There are no speed or reliability problems. Why the dia$par.Mirror works fast with large databases.

dia$par is integrated with Oracle 12c DBMS, a worldwide leader in processing large amounts of information.

This tandem makes it possible to scale up to one’s growing needs in a virtually infinite number of ways. Our clients are immune to infrastructural downturns — they can just go ahead and fully focus on developing further and making more and more money. The powerful system will only be facilitating this, for the possibility of forced and always painful (as reflected in the proverb "Moving once is like having your house on fire three times") migration to a different system is totally out of the question here.

At Ulmart, on a good day, they crank out around 100,000 documents.

UPD 23.04.2014?

In 2012, Ulmart generated up tp 200,000 documents per day, achieving even higher figures on certain peak days.
In 2013: approx. 270,000 documents per day, over a million commercial lines daily.

In dia$par terminology, a "document" is a transaction on the company’s resources. Documents are used to effect the "movement" of products, people, and money. dia$par capabilities make it possible to process volumes of transactions this high online with full functionality.

It is a common belief that maintaining high-speed operation with a large number of users requires the use of massive amounts of server equipment.

The major onus for execution speed lies in the domain of programming optimization of queries. And here Oracle has got the more developed language for queries and a powerful intelligent optimizer, which helps formulate fast executed, complex queries. For instance, it may take just one query to easily and accurately calculate warehouse inventory turnover. It equals Sales divided by Average Inventory. Average inventory is a
mathematically precise quantity, so there is no room for assumptions like "let’s go with the closing balance" and "our storekeeper John so-and-so knows for sure that blah blah blah". Here we specifically need to calculate the average value of the function of the warehouse stock balance:

We have checked it — the variance between the output of a regular arithmetic mean algorithm for calculating turnover and that of the correct one, provided above, is as much as 50%. Consequently, what you get is that it may take your inventory one to three weeks to turn over. So make your decisions based on the funding parameters.

In terms of architecture, any dia$par.Mirror is a three-tier application. Application servers are capable of forming a cluster. To calculate reports, application servers can use standby database servers, which can help distribute the load around and use the equipment on hand in a more effective manner.

dia$par.Mirror can work with considerably large tables containing up to 10 billion entries. Yes — work with, not store. The partitioning system places historically old, rarely used, data contained in a given table on cheap disks that are not so fast, while it puts fresh, in-demand, "popular" data on fast ones. That is all there is to it — there are no visible limits when it comes to requesting data, which means that dia$par.Mirror is free from such an atavism, historically inherent to brand-name solutions, as data archiving — all of your data is always available.

Being inside dia$par. Some stories
©
© 2020
U.S. Humanless Enterprises
contact us
U.S. customers:
Call me back
humanless service
We do NOT collect any visitor's
information, except given obviously,
and do NOT share it with third parties.