4 Replies Latest reply on Mar 26, 2014 9:47 AM by bsullivan@pharos.com

    Distributed Databases

    jorge@nyu.edu Wayfarer

      we currently have a central pharos db in new york city which serves 4 print servers in nyc. we have no issues at all with this setup. we are bringing on sites across the globe and we are seeing performance issues at some of these sites. what we would like to do is have multiple databases distributed around the world to process the local read/write activity and then sync back at a later time to our central db here in nyc. we are strictly looking at increasing performance for these sites.  i started to have a discussion about this with Bill Sullivan last week in dallas and he mentioned posting here. has anyone done something similar to this or does anyone have pointers on some things to try to improve performance when traffic is coming from australia or china back to nyc. thanks

        • Re: Distributed Databases
          Edmund Greene Wayfarer

          Jorge,

           

          At one time I had two different principle servers.  The problem with it was they could not talk to each other.  What I did was make a separate database on a complete other system and I would copy the important data I needed to that.  I was able to copy the transaction information to the independent database and use it to run reports for the total system.  You could make separated principle servers in the different areas and then copy the data to an independent database.  Of course, this creates the problem of synchronizing the user information and queue information across the servers.  It may not be the solution for you, but it is an option.

          • Re: Distributed Databases
            Steven English Guide

            Separating the databases also separates the ability to release jobs across print servers in addition to increasing the workload of having to merge the data from the separate servers.  The system is technically functional as-is, but in order to eliminate some of the delay that is inherent in distant/global connections, I believe that capabilities that Jorge is asking for would need to be implemented.  Technically speaking the delays would still be there, but they would be happening after the user's interaction with the Omega and devices when no one cares if it takes 5 seconds or 15 seconds to sync up to the system.

             

            Apart from the obvious benefit of optimizing user interaction speeds, you would also have the benefit of the system being less likely to trigger into an offline state as the database itself would be less likely to lose connectivity since it would be on the LAN instead of the WAN.  In essence, this would be a much more thorough and exhaustive implementation of the things that the proxy service is already doing as it has the ability to cache offline transactions and reconcile them to the server, it caches user credentials, and so forth.  The tricky part is ensuring that the user account information is not sent to more than one location and used simultaneously in an effort to cheat the system.  In the scenario just described, a user could potentially go into the negative as far as funds in the Pharos database are concerned; use of an external billing system such as BlackBoard or CBORD would offload the responsibility in that the billing system would be responsible for providing multiple access points for account balance queries and debit commands (or if a redundant system is not provided, then there is no need to worry about reconciliation as all billing would happen in real time).

             

            Regards,

            Steven

            • Re: Distributed Databases
              Steven English Guide

              Good Morning Bill Sullivan,

               

              Have you or your team had a chance to kick this around some as discussed at the conference?

               

              Regards,

              Steven