Data is growing at an exponential rate, and increasing automation is creating a flood of data from smartphones, mobile, and IoT devices, security systems, satellite imaging, cars, and other sources. The challenge then arises, how can we rapidly obtain useful insights from ever-growing data sets of various types and sources?

Graph technology allows developers and analysts to easily get significant insights by exploring relationships and discovering connections in data. Much of the world’s data is truly linked, including financial transactions, personal and professional networks, manufacturing supply lines, and so on. Graphs show those connections instantly.

Here’s an example of how data sets are linked and how complicated analysis might become as a result of data connections.

Graph data platforms enable developers to work more efficiently. They provide the performance and scalability required for big installations, while improved query and search capabilities simplify access and reduce time to insights for connected-data use cases.

Oracle makes it simple to implement graph technology. Oracle’s converged database includes graphs, which allow multi-model, multi-workload, and multi-tenant needs in a single database engine. The strength of built-in graph algorithms, pattern matching queries, and visualization in Oracle Database and Oracle Autonomous Database enable analysts to swiftly find new insights. Graph analytics may be readily added to existing systems by making use of Oracle Database’s performance, scalability, reliability, and security.

Oracle is recognized as a leader in graph data platforms

Forrester evaluated graph data systems using 27 criteria. Graph model/engine, deployment options, cloud, app development, API/extensibility, data loading/ingestion, data management, transactions, queries/search, analytics, visualization, high availability and disaster recovery, scalability, performance, data security, workloads, and use cases are some of the main criteria.

Why graph technologies from Oracle?

The following are key features of the Oracle offering:

1. Complete graph database that supports both property graphs and RDF knowledge graphs. Oracle Database makes it easier to describe relational data as graph structures. It simplifies the identification, processing, and visualization of linked data sets on-premises or in the cloud.
2. Enterprise-level scalability and security. Interactive graph queries can be executed directly on graph data or on a high-performance in-memory graph server, which can handle millions of concurrent users and queries per second. Customers benefit from fine-grained security, high availability, simple management, and connection with other data sources in business applications. Oracle offers advanced multilevel access control for property graph vertices and edges, as well as RDF triples. Oracle also complies with ISO and W3C standards for representing and designing graphs and graph query languages.
3. Comprehensive graph analytics to analyze relationships using over 60 prebuilt algorithms.  To generate, query, and analyze graphs, analysts can utilize SQL, native graph languages, JAVA, and Python APIs, as well as Oracle Autonomous Database capabilities. They may quickly display relationships in data to identify insights, and then publish and share analytical results using interactive analytics and visualization tools. Graph Studio in Autonomous Database allows practically anybody to get started with graphs to investigate data relationships. Graph Studio streamlines the graph analytics lifecycle by automating graph data administration and simplifies modeling, analysis, and visualization.

Graph analytics use cases

Money laundering detection in financial services: Users may develop a graph from transactions between entities as well as entities that share certain information, such as email addresses, passwords, and more, to make fraud detection easier. A single query will uncover all consumers with accounts that have comparable information, expose which accounts are participating in circular payment schemes, and detect patterns used to continue fraud after a graph has been formed.

Traceability in manufacturing: Traceability is extremely important in the manufacturing industry. A car manufacturer may have to recall a vehicle because it has a component that was produced at a facility within a specified time period. Most businesses have a production database, a retail database, a sales database, and a shipping database. Unless the business has a graph database to link all the relationships and graph algorithms to highlight connections and essential information, it is difficult to uncover all the relevant information to locate the automobiles with the problem, where they were delivered, and to whom they were sold.

Criminal investigation: Graphing data is a simple and efficient technique to detect criminal networks and search for trends. The use of graph-based algorithms makes it simpler to pinpoint specific places, highlight co-traveler links, and identify significant suspects and criminal groups. Users, for example, can determine the “weakest link,” or the vertex on which the graph is dependent, by using betweenness centrality. If you delete that vertex, the entire network may collapse, indicating that you have just discovered the linchpin of a criminal organization.

Data regulation and privacy: A graph is ideal for tracking data lineage. By tracing the edges, the many stages of the data lifecycle may be followed and browsed vertex by vertex. With a graph, it is able to trace a path and determine where the information originated, where it was copied, and where it was used. With all of this information presented in a graph, data professionals may more easily assess how to meet GDPR requirements while remaining compliant.

Product recommendations in marketing: Graph databases capture all data and connect it to deliver real-time suggestions based on client demands and product trends. Many major organizations rely on graph analytics to generate product recommendations since the linkages are already defined and the analysis of these relationships to provide suggestions is quick. Graph analysis may also uncover trends that expose trolls, bots, falsely boosted reviews, and information that may bias marketing analysis.

Summary

Graph technology facilitates the exploration of relationships and the discovery of connections in data. Pattern recognition, classification, statistical analysis, and machine learning may be applied to these models by users, including non-technical ones, allowing for more efficient analysis at scale against huge amounts of data.

In today’s customer-centric world, organizations find it difficult to grow their user base while meeting their customers’ speed, agility, and personalization needs—but that’s exactly what LogFire was able to do when it switched to Oracle Autonomous Database, a next-generation cloud platform with a fully automated database. LogFire raised order processing rates by 55% in a year while expanding its customer base by 2x. LogFire also decreased its TCO by utilizing Autonomous Database auto-scaling technology, going from ten external contractors administering the database to zero—the database automates all manual activities. LogFire now processes approximately 5 billion packets each year and is trusted by hundreds of clients worldwide. LogFire was also able to swiftly construct more features and customizations with Autonomous Database to grow into 10 new industries.

This blog will discuss how LogFire (now branded as Oracle Warehouse Management Cloud) migrated its cloud-native, mission-critical SaaS application to Oracle Cloud Infrastructure (OCI) and migrated all of its AWS PostgreSQL databases to Oracle Autonomous Transaction Processing (which also runs on OCI) for improved performance, elasticity, security, and TCO.

Oracle Warehouse Management Cloud, Born from LogFire

Oracle Warehouse Management Cloud is a leading cloud-based inventory and warehouse management service that assists organizations in automating numerous supply chain processes. LogFire, a pioneer in introducing cloud to supply chain management, was created in 2007 by Diego Pantoja-Navajas and was acquired by Oracle in 2016 as the foundation for Oracle WMS. “With the goal of revolutionizing supply chains by assisting organizations in adopting cloud technologies, we designed a standalone SaaS application that connected different systems and data to remove silos and make supply chains more efficient,” Diego explained during our chat. We were always aware that we were creating a mission-critical application for the heart and lungs. Because so many different types of enterprises would rely on it, it had to be bulletproof.”

Issues with Amazon Relational Database Service (RDS)

LogFire’s application used current cloud-native development approaches, with production databases on Rackspace running PostgreSQL. Arun Murugan, VP WMS Product Development, stated that they transferred their PostgreSQL test databases to Amazon RDS to save money, but maintained production on Rackspace and outsourced administration because LogFire did not have an in-house DBA staff. “While RDS eased scalability, it had performance and reliability issues that made it unsuitable for our production databases.” These issues included “no performance guarantees, manual tweaking of a huge number of database settings to maintain performance levels, no automatic bi-directional database replication, security vulnerabilities, patching and maintenance downtimes, and more,” added Arun.

LogFire’s architecture before moving to Oracle Cloud Infrastructure

Why LogFire Moved their Applications and Databases to Oracle Cloud Infrastructure

The supply chain, like any other business, is undergoing massive changes. The great toilet paper crisis of 2020, which coincided with the COVID-19 pandemic, showed another gap in the global supply chain. Social media exposure, the growing emphasis on customer experience, sustainability, ethical vendor conduct, and the circular economy have all had a significant influence on changing the supply chain from a back-office function to a more strategic differentiator. As a result, the importance of the supply chain was increased across sectors, and LogFire experienced a boom in demand that put a lot of strain on its previous design. LogFire prioritized innovation and modernization of its supply chain for its customers:

• They were unable to provide new features at the rate demanded by their customers.
• They were spending a growing amount of time manually maintaining their databases to assure their clients’ 24/7 availability.
• Most importantly, Rackspace’s production PostgreSQL databases were unable to scale up and down as quickly in response to seasonal peaks in demand as well as the yearly growth in shipment quantities of its retail customers. Despite the fact that their program could scale dynamically, scaling and upgrading the databases required downtime, making the databases inaccessible and slowing down the whole process. They had to prepare ahead of time and acquire more Rackspace servers before each seasonal peak, then manually scale down at the conclusion of the season. Scaling on AWS also necessitated downtime.

Because these basic difficulties were impeding its expansion, LogFire began examining other possibilities that may meet its business objectives. After analyzing all of the benefits, they decided to transfer their application and databases to OCI in the summer of 2019. They converted all 700 PostgreSQL databases to Autonomous Transaction Processing, an Oracle Autonomous Database optimized for OLTP, after a comprehensive evaluation of several possibilities for operating PostgreSQL databases on OCI, or Oracle Autonomous Database.

Oracle Warehouse Management Cloud architecture on Oracle Cloud Infrastructure

Seamless Migration Process

The conversion of LogFire’s application and database to OCI and Autonomous Database took slightly over 7 months. If not for the delays to minimize any inconveniences for its retail clients during their seasonal peaks, the full move would have taken less than three months. They had switched their whole application stack and all of their clients on OCI by February 2020. The following criteria helped all 700 databases migrate successfully.

1. LogFire’s application was created with a modern cloud-native REST services-based architecture. Just because of that, moving to OCI was as simple as raising and shifting the application code to Oracle’s cloud-native services without significant re-architecting or rewriting of the code. They used API calls to connect to a number of non-standard systems to automate package selecting, packaging, sorting, and shipping. Moving their 700 PostgreSQL databases was the same as changing the core database technology without the need for additional integrations.
2. The Django object-relational mapper (ORM) is used in LogFire’s application architecture to create a database separation layer, allowing queries to be database-agnostic. This meant that 75 % of the SQL queries created by the ORM could be sent to Oracle “as is.” Only 25% of the hand-coded queries required some level of tweaking for Oracle Autonomous Transaction Processing.
3. Because PostgreSQL and Autonomous Transaction Processing are both SQL-based, LogFire developers and users had a relatively low learning curve because ATP automates the majority of the operations.

How the Move to ATP from PostgresSQL Propelled LogFire’s Growth

55% increase in order processing speed: Warehouse management systems are real-time transaction systems in which order delivery is directly affected by performance and availability. Several systems, robots, and machines make continual API calls to the database to complete a single order. As order volumes grow, database failures or slower response times have an impact on income and, eventually, reputation. Only Autonomous Transaction Processing could meet these high-performance standards. However, switching to OCI raised LogFire’s clients’ order processing rates by 55%, while goods sent increased by 45% year over year.

50% increase in warehouse users: Diego stated that after migrating to OCI, LogFire was able to grow from five industries to fifteen, expanding its customer base and increasing warehouse users by 50% in just one year. Because their workers had access to all data and could focus on development rather than managing the database and supporting infrastructure, they were able to quickly introduce new features and modifications for these new sectors. Autonomous Transaction Processing allowed this expansion by enabling auto-scaling at the press of a button, even during seasonal peaks when LogFire’s customers doubled their users.

In fact, during the start of the pandemic, most of their clients’ shipment volumes exceeded their seasonal peaks. LogFire was also able to satisfy the unanticipated rise in demand efficiently and without disturbance. The auto-scaling functionality of the Autonomous Database may automatically scale up or scale down the number of CPUs based on workload needs, resulting in cost savings through real pay-per-use.

TCO Reduction: LogFire decreased its ownership costs by transitioning from a remote database management service with 10 contractors continually monitoring all of their databases to a completely automated system. Autonomous Transaction Processing automated all of its processes, allowing for error-free 24/7 monitoring and avoiding continuing maintenance costs for patching, protecting, and backing up the databases.

Zero Downtime: PostgreSQL databases hosted on AWS or Rackspace required scheduled downtime for patching, upgrading, and maintenance. Autonomous Transaction Processing grows dynamically while transactions are in flight, automatically installs updates with no downtime, and does not require planned maintenance. It generates and manages multitenant environments automatically, manages clusters, and implements Oracle Maximum Availability Architecture (MAA). The Autonomous Data Guard (Auto-DG) function, which may be activated with a single click, automatically produces a standby duplicate of the active database.

In the unlikely event of an interruption or outage, the database layer can instantly transition to the standby database. Rather than waiting for the primary database to recover, application transactions can continue to run without interruption on the promoted backup database. Transparent Application Continuity improves the availability of the database that is already running on Oracle Real Application Clusters (RAC). These features enhanced LogFire’s uptime SLA, assuring zero downtime.

Enhance Security: LogFire improved its security posture after switching away from PostgreSQL. Their data was secured only during transmission using AWS RDS for PostgreSQL. Transparent Data Encryption (TDE) is used by Autonomous Transaction Processing to encrypt data both at rest and in motion. It uses machine learning to automate the detection of security risks. It also offers more granular security to do assessments, disguise sensitive data, and audit actions in order to secure customer data. Security fixes are also applied automatically.

Machine Learning-based automation: By exploiting the in-database machine learning techniques available with Autonomous Transaction Processing, LogFire was also able to distinguish and deliver unique value to its clients. They used over 150 distinct AI/ML algorithms without the help of any data scientists. The following are a few AI/ML algorithms that they implemented:

• Predicting peak hours in distribution centers
• Calculating average picking times and expected task time
• Replenishment (automatically initiating efficient replenishment tasks)
• Calculating expected profit from each order fulfilled or average revenue generated per order
• Predicting future target values
• Creating predictive pick orders based on historical data
• Automatically assigning order fulfillment priority
• Clustering employees who work well together to optimize efficiency
• Warehouse slotting
• Spotting worker efficiencies

As cloud technology advances to enable business-critical applications for all types and sizes of enterprises, the migration of data, databases, and apps from on-premises settings to the cloud is quickening. Many of our customers, like you, have begun to make this transition and are evaluating their choices for moving their on-premises Oracle Database workloads to the cloud. There are several variables to consider before starting on your cloud journey.

Many organizations that run Oracle Database Standard Edition on-premises for OLTP, analytical, or mixed workloads are thinking about upgrading to a fully managed Oracle Autonomous Database in Oracle Cloud Infrastructure (OCI) or consolidating many databases in their data centers using Autonomous Database on Exadata Cloud@Customer. Let’s look at the commercial and technological benefits in this scenario.

Why Upgrade to Oracle Autonomous Database?

There are some convincing reasons to migrate your Oracle Database Standard Edition on-premises to Autonomous Database in the cloud:

• Autonomous operations: Autonomous Database, being a fully managed service, removes the huge majority of labor-intensive manual DBA activities. It optimizes performance and availability by using machine learning and decades of production-proven best practices. Autonomous Database provides a completely self-contained experience that includes automated database tuning, scaling, patching, and security features. As a result, Autonomous Database does not need substantial database administrator and infrastructure management knowledge, lowering operating expenses and freeing up resources for more vital business goals. Autonomous features built within new products and services, such as Oracle APEX and AutoML, improve application development cycles and reduce time-to-first-revenue.
• Advance features: 
  • Moving to Autonomous Database provides industry-first features that are designed to tackle persistent user problems that need expert-level administrators doing manual database diagnostics, performance tuning, capacity planning, manual backups, and security tasks. These and other issues are clearly stated by Autonomous Database features that are not accessible with Oracle Database Standard Edition. Instead, machine learning optimizes database performance in real-time, ensures patches are applied correctly and without disruption, detects and remediates unauthorized intruders as soon as they attempt to access your data, and scales performance and capacity up and down based on demand—all without disrupting operations.
  • That isn’t everything. The Oracle Autonomous Database contains all of the features and capabilities of the Oracle Database Enterprise Edition, including several that are not accessible in Standard Edition situations. Transparent Data Encryption (TDE), multiple container databases (CDB), partitioning, compression, parallel query, in-memory columnar format, sophisticated analytics, and other features are available. You may also receive Autonomous Database on Exadata Cloud@Customer in Oracle Cloud Infrastructure (OCI) or in the comfort and convenience of your own data center.
• Latest infrastructure: Your on-premises devices might be several years old. Its maintenance period or lifetime may likewise be coming to an end. Because: (1) there is no hardware investment, and you pay only for the resources that you use in a subscription service; and (2) Autonomous Database operates on Oracle Exadata infrastructure that is specially and uniquely architected for the best Oracle Database performance in the cloud. Customers with substantial Standard Edition installations and data sovereignty concerns can also migrate to Autonomous Database by operating it on Exadata Cloud@Customer in their data centers or co-location facilities like Equinix.
• Higher performance: Oracle Autonomous Database has been shown in the field to improve application performance. Autonomous Database optimizes OLTP, analytics, and mixed workload performance by utilizing strong Exadata technologies like Smart Scan query offloading, Smart Flash Cache, and Automatic Indexing, which are not available in Oracle Database Standard Edition. Queries are substantially quicker when SQL queries are optimized and data-intensive and compute-intensive workloads are offloaded to intelligent Exadata storage servers. Workloads will take fewer vCPU-seconds to complete, resulting in decreased expenses.
• Consistent data protection and security: Applying the most recent software patch is usually easier said than done, especially when you need to patch your complete stack of server, storage, and networking infrastructure in addition to Oracle Database. Because of the difficulties of evaluating the compatibility of patches from different vendors, patching self-managed databases and infrastructure is sometimes delayed by more than three months after updates are released. Delays in patching expose consumer databases to security vulnerabilities, even when a workaround is available. When new security patches become available, Autonomous Database automatically and non-disruptively deploys them throughout the database stack.
• High availability: Autonomous Database achieves more than 99.95% availability by combining completely redundant Exadata infrastructure with Oracle Real Application Clusters (RAC), Autonomous Data Guard, automatic backups, and automated failure detection and failover in OCI.
• Automatic scaling: Autonomous Database adjusts vCPU use up and down depending on actual workload requirements, not on some speculative prediction of peak resources at some distant period in the future. Customers frequently outgrow both cloud and on-premises infrastructures to minimize the downtime and expense associated with upgrades. Autonomous Database in OCI and Exadata Cloud@Customer minimizes downtime by enabling online resource scalability and preventing over-provisioning by automatically optimizing both performance and cost. Typical on-premises systems obviously do not allow online resource consumption, and most database cloud services do not let it either. With Autonomous Database’s per-second pricing, you only pay for the resources you use, not what you anticipate you might need in the future.

Use BYOL to Lower Your TCO

Lowering the total cost of ownership (TCO) by shifting to the cloud is vital for a CFO or CIO. Moving to the public cloud eliminates the need for enterprises to pay for hardware and data center-related expenditures such as electricity, cooling, data center networking, and physical security. By automating database operations and monitoring, migration to Autonomous Database can save database management expenses by up to 80%. Furthermore, intelligent scaling can cut runtime costs by charging you only for the resources that are necessary at any given time.

Even when comparing Autonomous Database to other general-purpose cloud architectures, Wikibon’s David Floyer found that migrating to Autonomous Database for transaction processing reduces total IT costs by 48% when compared to on-premises systems and reduces the expected cost of downtime by up to 70%. This is due to the design of the Autonomous Database, which provides increased speed, ultra-low latency, high degrees of consolidation, decreased downtime, and faster recovery.

When calculating TCO, keep in mind that Oracle provides Oracle Bring Your Own License (BYOL), which can significantly lower expenses. With this BYOL initiative, you may speed your cloud migration path by converting on-premises software licenses to similar, highly automated services in OCI. In the instance of this blog’s migration scenario, the BYOL program provides a 76% reduction on the price of Autonomous Database with License Included. You get the same 76% savings whether you bring Oracle Database Standard Edition or Oracle Database Enterprise Edition licenses to Autonomous Database, so bringing Standard Edition is very appealing.

For example, NEC Nexsolutions used this BYOL tool to migrate their retail application from on-premises Oracle Database Standard Edition to Autonomous Database. Aside from cost savings from BYOL, running Autonomous Database for a transactional processing workload on a dedicated Exadata environment in OCI resulted in improved security for NEC Nexsolutions, as well as access to autonomous functions, such as security threat detection and remediation capabilities.

Reduced Administration Efforts = Increased Opportunities and Lower TCO

Because it is a completely managed service, Autonomous Database helps enterprises to save up to 80% on database administration expenses. It reduces the time IT professionals spend on operational operations like provisioning, scaling, tuning, backups, and failover preparation, allowing them to focus on strategic business goals. Clearly, businesses must account for the impact of reduced labor costs in their TCO calculations.

Lowering Cloud Migration Risks and Costs

Any type of migration may be complicated, difficult, and expensive. Oracle provides cloud engineering services and free technical tools to simplify Oracle Database migrations from on-premises to OCI while minimizing unnecessary expenses.

With Oracle Cloud Lift Services, your IT teams can perform rapid cloud migrations with the help of Oracle Cloud professionals. These experts can advise you on Oracle migration strategy, architecture, prototyping, and management. Even better, all existing and new Oracle Cloud customers globally have access to these resources at no additional cost.

Oracle also provides two free migration technology options: Zero Downtime Migration and OCI Database Migration Service. Zero Downtime Migration is a solution that may be installed to allow a simplified and automatic migration with zero to near-zero downtime. It allows for migration between a wide range of Oracle Database sources and target configurations, such as from on-premises Oracle Database Standard Edition to Autonomous Database. OCI Database Migration Service, on the other hand, is a managed OCI service that utilizes Zero Downtime Migration. It migrates Oracle databases to OCI with little to no downtime and provides a simple user interface for a quick self-service migration experience. You can select a migration option depending on your company’s needs.

Additional Benefits that Future-Proof Your Cloud Investment

Moving your existing workload from on-premises Oracle Database Standard Edition to Oracle Autonomous Database provides you with additional benefits that will protect your cloud investment in the future.

Consider performance. Workloads on NEC Nexsolutions’ Autonomous Database operated more than five times quicker than previously. By utilizing Exadata’s database-optimized technology, automatic tuning, and indexing, Autonomous Database achieves low latency and high throughput. Higher performance results in multiple advantages for internal and external service consumers, including faster processing time for critical business transactions, the ability to serve more customers, improved customer satisfaction through increased responsiveness, faster-resolving issues, and more. As previously stated, quicker processing times minimize cloud usage costs since you only pay for resources consumed.

Autonomous Database increases the efficiency of your developers as they upgrade and grow your organization’s business applications. Autonomous Database, being a unified database that supports transactional, analytic, and data warehousing workloads, enables easier and faster software development and provides a wide range of features. In-database machine learning (ML) algorithms, support for a wide range of data formats (e.g., JSON, XML, relational, geographic, graph, IoT, text, and blockchain), and REST APIs enable development teams to build sophisticated applications without the need to link different services. Oracle APEX Application Development is also available from Autonomous Database for no-code/low-code application development.

Oracle Cloud Native Services, such as Container Engine for Kubernetes, allow developers to easily create and expand advanced applications by using a microservices design that incorporates database capabilities. Although some of the listed features are also accessible with Oracle Database Standard Edition, having access to a wide range of OCI services allows developers to focus on innovation rather than development tools and manual service integration.

Most data science experiments begin with a few data files on a laptop and then use algorithms and models to anticipate a result. Although the method requires little initial computing, data scientists rapidly learn that their workloads demand more computational power than a local CPU or GPU can give. As a result, they’re compelled to create a rapidly scalable computing solution. The Oracle Cloud Infrastructure (OCI) Data Science platform fits into this category, addressing the need for changeable size and performance.

When a data scientist considers employing cloud resources, the following questions can be asked:

• Is cloud computing capable of scaling up to meet the workload?
• Can I achieve performance comparable to or better than my laptop or on-premises machines?
• Is this a cost-effective move?

Data scientists may utilize the major criteria that drive responses to these questions as a guideline to prepare and get the most out of the OCI platform by reading this article.

Workload

The first stage in the process is to understand your workload and its peculiarities. A data science program’s workload is described as the quantity of computing work performed on a certain computational resource, such as a laptop, on-premises server, or a cluster of workstations. It covers memory, I/O, and CPU or GPU-intensive tasks. The workload is calculated by multiplying the number of CPU or GPU cores by the number of computation hours.

As a result, you must be aware of the following critical elements that influence workloads:

• Your longest-running job has a maximum compute hour limit.
• Your longest-running task at 80–90% CPU or GPU usage.
• Average CPU or GPU utilization: What proportion of the CPU or GPU is used on average?
• Average workload hours per day or month: The percentage of time your machine is active rather than idle.

The first two criteria identify the type of your most demanding task and provide an estimate of the number of computing cores and storage space needed to meet your performance goals. The remaining two elements are concerned with resource idle time and the cost implications for your performance target.

If the maximum computing hours exceed your performance requirements, you’ll need extra compute cores, and running workloads in OCI for higher performance may be beneficial. If your typical monthly workload hours are low and your machines are idle the majority of the time, OCI Data Science’s on-demand computing infrastructure can help you save money on idling charges.

Installation, configuration, data intake, and preparation may all be factored into your workload. These manual chores are required in all data science initiatives. These activities usually don’t require much computing power and may be completed with a small amount of CPU time. You may, for example, install Anaconda and configure it on a low-end Compute shape and then transfer it to a bigger core CPU or GPU as you run your algorithms and iterations.

Installing software many times, managing configurations, and dealing with version and library incompatibilities all take time away from productive work. Using a pre-built environment that functions consistently in a team context reduces this time to a fraction of what it would be otherwise.

CPU and GPU

The performance of your Data Science application is influenced by the CPU or GPU. To estimate the appropriate computing needs, it is necessary to grasp a few important factors.
Cores, threads, and clock speed are the most important characteristics of a CPU. Individual processors are stacked within the CPU chip as cores. Threads define how many tasks a CPU core can perform at the same time, often known as simultaneous multithreading or hyperthreading. The number of threads is usually double the number of cores.

A processor’s clock speed in GHz indicates how fast it can execute per second. When two processors have the same number of cores, the one with the higher clock speed performs better. Because the former has a greater clock speed, a 10-core Intel i9-10900 is similar to a 16-core AMD Ryzen 9 5950X.

A stream processor, CUDA or tensor cores, GPU VRAM memory, and memory bandwidth are all features of a GPU. AMD’s stream processors and NVIDIA’s CUDA cores refer to a single, exact calculation, whereas tensor cores compute a whole matrix operation per GPU clock cycle and are 5–8 times quicker. How fast the GPU can access and use the vRAM is determined by the GPU vRAM, built-in vRAM in a GPU card, and memory bandwidth in MHz. Executing the nvidia-smi tool on an NVIDIA GPU provides real-time GPU and vRAM usage while your task is running.

As a result, you may explore and decide the best CPU or GPU processor shape for your task. For example, MLPerf is an open-source measuring tool that compares CPU and GPU performance for both machine learning training and inference workloads and tools. Benchmarks for deep learning on the CPU and NVIDIA GPU can also give useful information.

Matching the setup with OCI Compute shapes leads to predicted performance on an OCI Data Science shape once you’ve determined the best processor for your job. However, because workload characteristics vary greatly, evaluating your personal workloads is the most reliable approach to determine what works best for you.

Environment

Your Data Science environment also has a big influence on Compute shape size and achieving the desired price-performance ratio. A high-capacity CPU or GPU isn’t necessary for installing or establishing an environment, or when performing data analysis or preparation tasks. Similarly, if you’re just getting started with algorithm testing or model training, a few CPU or GPU cores may be plenty.

When you increase your training burden, you’ll still need more cores and memory. The Compute form is influenced by how a trained model infers production data. Predictions on big batches of data and high-frequency concurrent queries, for example, necessitate CPU and GPU scaling in terms of cores and nodes. Latency is a critical aspect of inferencing, and increasing the number of cores or nodes in a computing structure is essential to strike the right balance.

Data science workloads are frequently run not just on various Compute shapes, but also in various Conda settings. Only GPU-based environments can employ PyTorch, TensorFlow, or CUDA, however ordinary pandas, sklearn, or Oracle Accelerated Data Science environments may do data exploration and preparation.

As a result, dividing the surroundings according to the type of work done might be beneficial. Working with distinct Conda contexts for a job is part of this approach. You need the ability to move between environments fast and grow to compute cores without compromising your installed environment base. To take advantage of price-performance and migration expectations, you’ll need to strike the correct mix between employing an on-premises environment and an on-demand OCI environment.

Existing segregated data science, for example, maybe OK at first, but as a data science team grows, a consistent environment management technique and collaborative code-sharing are essential. Consider the implications and critical elements, such as performance, growth, cooperation, and cost, when assessing the total infrastructure.

Data residency and volume

In order to make data appropriate for data science processing, about 70% of each data science effort is spent on data input, cleaning, and preparation. When huge batches or streams of data need to be handled, this workload might grow exponentially, necessitating the use of a bigger, auto-scalable compute resource. When the essential data is spread across on-premises and several clouds, this procedure becomes much more difficult. Consolidation, deduplication, and consistency of data become significant challenges.

In such cases, copying the essential data to a common platform, such as a data lake, which you can then process with data transformation tools located closer to the data, is often the simplest and most cost-effective solution. This architecture necessitates the adoption of an auto-scalable storage solution, and on-demand solutions such as OCI Lakehouse can help.

Cleaning and preparation methods differ between structured and unstructured information, as well as between smaller batches and streaming datasets. For example, SQL-based cleaning operations inside an OCI autonomous database or Apache Spark-based in-memory batch processes may successfully clean huge relational structured data. Because a bigger data collection necessitates greater storage, access, and data processing time, lakehouse sizing becomes important.

Moving data science models closer to data, on the other hand, is a critical component that allows a data scientist to focus on the most important activities, such as model development, selection, and predicted explainability, rather than transferring enormous amounts of data. When data is spread, data scientists may run workloads in silos, however, when data is consolidated, they may run workloads together on a single platform like OCI. The principles are the same in both methods, but the latter is easier to administrate and apply. You can effectively scale computing and storage for data science outcomes in these circumstances.

Architecture and Integration

The architecture of your data science tools and components relates to how they integrate and interact with one another. Evaluate various tools, their production usage, and their interaction points to determine how they can deploy or grow with a data science implementation if your data science infrastructure is coupled to on-premises solutions or a cloud vendor. The smaller the criticality and reliance on integration points, the easier it will be to migrate, scale, or burst into the cloud.

If your environment is imaged and infrastructure is scripted, as in Terraform, deploying on OCI and taking advantage of the performance, flexibility, and cost savings it provides can be more beneficial. In another case, moving big, rare training workloads to the cloud while maintaining production inference workloads on-premises can improve overall performance and save money. This hybrid cross-cloud architecture with right-sized Compute shapes may have a significant influence on overall company performance and profitability if properly automated and reported.

Conclusion

You may examine your existing or anticipated Data Science environment by evaluating all of these aspects and deciding if transferring your data science workloads entirely or partially to OCI makes sense for your workload. When you have a concept, utilize the Oracle Cloud Estimator to see how your analysis compares to a small, medium, or big implementation. After that, choose reference architectures and Data Science.

You may also tailor and right-size your Data Science environment to meet your specific requirements. Oracle Cloud Infrastructure Data Science is dedicated to assisting you in making the best decision possible.

The first and only autonomous operating environment is Autonomous Linux, which is based on Oracle Linux. It maintains the operating system patched automatically, reducing complexity and human error while also increasing security and availability. Oracle OS Management Service in Oracle Cloud Infrastructure now manages Autonomous Linux instances by default (OCI). You may easily transition historical Autonomous Linux instances that were installed using the July 2021 or previous images to make use of the functionality provided by the OS Management Service integration.

Automatic discovery and OS management

Before creating an instance in OCI, you must first fulfill the conditions and set up the OCI policies to allow management. The Autonomous Linux image is accessible as an OS platform image in OCI and may be installed in a matter of seconds. OS Management Service automatically discovers and manages autonomous Linux instances deployed from current platform images in OCI. Through the Oracle Cloud Console, you can establish the daily auto-update schedule and monitor important system events and resources using the Autonomous Linux interface with OS Management Service. You may manage Autonomous Linux instances with Oracle Linux and Windows Server instances with OS Management Service using a single user interface. Customers of OCI can use the OS Management and Autonomous Linux services for free.

Migrating legacy Autonomous Linux instances

By default, Oracle Autonomous Linux instances using the August 2021 Oracle-Autonomous-Linux-7.9-2021.08-0 platform image or later are connected to OS Management Service. The alx-migrate script may be used to migrate instances installed with an Oracle Autonomous Linux July 2021 Oracle-Autonomous-Linux-7.9-2021.07-0 image or earlier to interact with OS Management Service. When you use the alx-script to migrate Oracle Cloud Marketplace images, such as the legacy Autonomous Linux version of Oracle Linux KVM, you may make use of the newest capabilities in OS Management through the Console.

The alx-migrate tool cannot be used to upgrade autonomous Linux instances installed on Oracle Cloud Free Tier Compute resources to interface with the OS Management service. OS Management Service does not support instances placed on Free Tier computing.

The methods below demonstrate how to transition existing traditional Autonomous Linux instances to OCI using OS Management. The manual contains extensive instructions.

1. For Autonomous Linux, configure the needed OCI Identity and Access Management (IAM) rules. Create a dynamic group for the OS Management service that defines the group members, and add a rule for the dynamic group that defines the set of instances allowed in the policy. In either your tenancy or compartment, make sure you’ve specified the relevant Identity and Access Management (IAM) policies for Autonomous Linux.

2. On the instance, make sure the OS Management Service Agent and Oracle Autonomous Linux plugins are turned on. Enable these plugins if they are currently disabled.

3. Install alx-migrate:

$ sudo yum install alx-migrate

4. Run alx-migrate:

$ sudo alx-migrate

5. Accept the OS Management Service terms of service. Run the alx-migrate script with the —accept-terms or -a option to accept the terms automatically.

$ sudo alx-migrate --accept-terms

Check to see if the migration was successful. To assist you in resolving probable issues, the documentation includes a message table.

The alx-migrate program removes the al-config RPM RPM package after a successful migration because it is no longer required. Instead of using the al-config application, the Autonomous Linux service controls autonomous settings through the Console after migration. See Managing Autonomous Linux Settings for further details.

Customer service has evolved into much more than just addressing complaints and resolving difficulties throughout a customer’s end-to-end experience. From the initial inquiry to product purchase, usage, and support, service is now a vital aspect of the whole customer experience (CX).

Consumers’ expectations of the brands they select are changing as well. According to a Five9 poll, 83% of decision-makers felt that the customer service experience is critical for client retention, and nearly all (99%) stated that customer service is crucial and necessary for their organizations.

We’ll look at how you stay up with evolving consumer expectations by providing really distinctive customer service experiences in this blog on digital-first service.

A successful digital-first service strategy requires unique service experiences

Given the growing importance and extent of service, a customer’s connection with the service department will most certainly be the most common—and important—brand engagement. As a result, providing unique and personalized digital-first service experiences to customers is becoming a necessity—one that is closer than you would think.

Customer care that is one-of-a-kind does not mean providing concierge-level assistance to every customer or finding fresh solutions to every problem. It all boils down to using data to have a deeper understanding of your clients.

Every business has access to a variety of information gleaned from sales, service, marketing, supply chain, and other departments. Break down your data silos and use the information to better understand your consumers’ requirements, interests, historical trouble areas, conversational styles, and special characteristics. Then, to assist you to allow unique experiences, build and organize service procedures that will eventually result in happy and loyal customers.

Tracking online surfing data, for example, may be used to improve a potential customer’s learning and inquiry experience by leading them back to their chosen homepage when they return days later. When a consumer logs in to your site after delivery, track the status of their order and instantly question if the shipment came as expected. Alternatively, segment consumers to provide personalized service experiences depending on the current context, such as an impending winter storm or their latest payment plan setup.

Three ways you can facilitate unique service experiences with Oracle Service

Oracle Service helps your company to provide exceptional customer service. Oracle Service can help you with capabilities like Agent Insights, Digital Assistant, and a direct Oracle Unity integration.

1. Empower your employees with a single, dynamic view of the customer

Our modern agent portal provides real-time client intelligence to agents, allowing them to provide tailored support. They may use AI to identify the best next steps and create a personalized experience for each consumer.

2. Deliver persistent customer intent

Use historical data to forecast what a client will try to do during their next engagement with your business, and then spread that knowledge across all channels (digital self-service or supported assistance) to make the process as simple as possible. Set all service channels to bypass the regular service flow and instead enquire about their interest in a late check-out if your hotel visitor is due to leave today.

3. Personalize interactions with modern assisted-service channels

Give customers access to digital channels they anticipate, such as live chat, social messaging, and SMS. Offer high-touch visual interaction alternatives like video chat and screen co-browsing for even more customized service.

Organizations may stay competitive and satisfy contemporary consumer expectations with digital-first service experiences by providing unique customer service. Check out the previous posts in our blog series to discover more about Oracle’s current vision for delivering holistic brand experiences with service, and stay tuned for the next topic on increasing your CX with hyper-convenient service.