Pixid replaced Oracle Database with MySQL in 2011, then soon migrated to MariaDB to get better performance, more features and synchronous clustering for high availability. In addition to high-performance transactions, their customers needed access to fast analytics for self-service reporting and data exploration. Pixid started with a separate columnar database for analytics, but with the release of MariaDB ColumnStore, they found a more elegant solution – deploying a single database platform to handle both transactions and analytics. In this session, Antoine Gosset and Jérôme Mouret share how Pixid went from Oracle Database to handling both transactional and analytical workloads with MariaDB.
2. 1
Overview
1. Pixid presentation and context
2. Migration from a standalone Oracle server to MariaDB Cluster
3. Migration from a standalone InfiniDB server to Columnstore multi servers with data redundancy
4. Implementation of the remote DBA offer to focus on our core business
5. Assessment
3. 2
2008
Comprehensive
solution for large
accounts
2012
SMB solution
launch
myPixid is born
2014
New Retail clients &
Candidates offers
for staffing
companies
2015
Management buy
out
Business plan incl.
International
strategy
2017
Acquisition Internet
Corp.
Offices in London
First projects in
Belgium & Germany
2004
Founded by Adecco,
Manpower &
Randstad
2018
Acquisition Carerix.
Offices in Rotterdam
1/3 revenue outside
France
Revenue €25m
History of PIXID Group
Revenue €10m
Revenue €4m
4. 3
200 employees
FR, UK, NL + R&D
+ 1,5 million
R&D investment / year
16 millions
revenue 2017
+ 23%
290 000
connections per month
90 millions
digitised documents
180 000
assignments per day
30 % of the French
temporary work market
536staffing companies,
7 800 branches
120 000
Registered client locations
2 120 000
temporary workers pool
The activity Our clients
1st worldwide editor
SME segment
(SIA Landscape VMS 2015)
5th worldwide editor
temp spend
(SIA Landscape VMS 2015)
613thEurope’s fastest
growing company
+ 165 % of rev.between2012 and 2015
(« FT 1000 – 2017 » / Financial Times)
PIXID Group in numbers
Figures & Awards
5. 4
A unique approach from customers to candidates
The PIXID Group proposes nowadays a unique
approach from customers to candidates with the
best of breed technologies, renowned on their
markets.
This double expertise can provide through the
integrated solution myPixid :
• Applicants management from sourcing to
placement
• Clients management from requisition to invoice
in an unrivaled ecosystem where all the actors of
workforce management are involved on their
territories.
6. 5
Our clients & their expectations
Corporate
Have access to the best skills
Manage all types of workforce :
from permanent to flexible
resources (temp, freelance,
fixed-term …)
Be compliant in any case
Optimize and control the cost of
flexibility
Recruitment agency
Speed up the resource proposal to
a client requisition
Attract candidates
Organise and qualify efficiently
their talent pool
Retain customers and candidates
Intermediary
Have access to various
resources acquisition channels
Propose efficient digital
services to their customers
Guarantee the compliance of all
processes
7. 6
Goals and strategy
PIXID offers a pure SaaS application to manage temporary workforce, in
compliance with the constraints of regulations enabling its customers to achieve the
following four objectives:
• Speed up the match between a candidate and a client request
• Guarantee access to the best skills as quickly as possible
• Give users a simple, fast and consolidated view of HR and financial data
• Simplify and make reliable all the administrative tasks
PIXID aim is to be the first European provider in Flexible Workforce Digital
Management from sourcing to management solutions.
9. 8
• Information Security
Management System applies
to an area that may be
restricted
• Monitoring and certification
audit is planned in advance
• Certification is voluntary
• The law applies to all
processing of personal data
• The authorities controls are
sometimes carried out without
any notice period
• Compliance is mandatory
ISO 27001 Certified ISMS + GDPR compliance = The best
protection for our clients data
Security and compliance
Intangible nature of data makes it particularly vulnerable with regard to the criteria of
Availability, Integrity and Confidentiality which form the basis of our security policy.
10. 9
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
Architecture 2004-2011
11. 10
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
Number of web sessions
12. 11
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
Architecture 2011 with MySQL
13. 12
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
The main migration steps:
• Adapt the schema for MYSQL. In particular on field types and the encoding.
• Migrate data in the new schema (Almost 100Gb in live environment) with a simple and
powerful tool SQLWays of Ispirer. (https://www.ispirer.com)
• Modify our application code so that the writings are made exclusively on the master and a
maximum of readings on the slave.
• Performance tuning around mysql and particulary the innodb engine variables.
14. 13
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
Several important performance variables to becareful:
• innodb_buffer_pool
• innodb_flush_method (O_DIRECT)
• innodb_buffer_pool_instances
• innodb_thread_concurrency
• innodb_io_capacity
• innodb_write_io_threads
• innodb_read_io_threads
• innodb_open_files
• sort_buffer_size
15. 14
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
MONyog Monitoring
16. 15
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
MONyog performance metrics
17. 16
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
MONyog slow query analyzer
18. 17
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
SQLyog query editor
19. 18
2. Migration from a standalone Oracle server to MariaDB (1st step)
SQLyog tools & powertools
20. 19
2. Migration from a standalone Oracle server to MariaDB Cluster (1st step)
ZMANDA Recovery Manager
21. 20
2. Migration from a standalone Oracle server to MariaDB Cluster (2nd step)
Architecture 2015 with Maxscale
22. 21
2. Migration from a standalone Oracle server to MariaDB Cluster (2nd step)
Final architecture 2015 without Maxscale
<datasource jndi-name="java:/datasource/MySQLDS" pool-
name="MySQLDS" enabled="true" use-java-context="true">
<connection-
url>jdbc:mariadb:replication://MASTER1:3306,MASTER2:3306,M
ASTER3:3306/maindatabase</connection-url>
<driver>mariadb</driver>
<transaction-
isolation>TRANSACTION_READ_COMMITTED</transaction-
isolation>
...
...
...
</datasource>
23. 22
3. Migration from a standalone InfiniDB server to Columnstore multi servers with data redundancy
24. 23
3. Migration from a standalone InfiniDB server to Columnstore multi servers with data redundancy
BI architecture: Single node
25. 24
3. Migration from a standalone InfiniDB server to Columnstore multi servers with data redundancy
26. 25
3. Migration from a standalone InfiniDB server to Columnstore multi servers with data redundancy
Columnstore architecture 2UM/2PM
27. 26
3. Migration from a standalone InfiniDB server to Columnstore multi servers with data redundancy
Final Columnstore architecture 1UM/2PM
28. 27
3. Migration from a standalone InfiniDB server to Columnstore multi servers with data redundancy
Important parameters:
Version buffer :
MariaDB ColumnStore uses the Version Buffer to store disk blocks that are being modified,
manage transaction rollbacks, and service the MVCC (multi-version concurrency control) or
"snapshot read" function of the database. This allows it to offer a query consistent view of the
database. PM side
max_length_for_sort_data :
Used to decide which algorithm to choose when sorting rows. If the total size of the column data,
not including columns that are part of the sort, is less than max_length_for_sort_data, then we
add these to the sort key. This can speed up the sort as we don't have to re-read the same row
again later. Setting the value too high can slow things down as there will be a higher disk activity
for doing the sort. UM side
29. 28
4. Implementation of the remote DBA offer to focus on our core business
Secure authentication
30. 29
4. Implementation of the remote DBA offer to focus on our core business
Main use cases:
• Analysis in case of performance issues
• Delivery of SQL scripts during deployment if necessary
• Technical and performance validations
• To update our databases or install patches
31. 30
5. Assessment
To resume:
• A very effective advice and support from MariaDB consultants.
• A migration of our main transactional database from Oracle to MariaDB Cluster that will
have been completed over time in several steps. But by meeting our performance
constraints and the growth of our activity.
• A simple start with fast and efficient scalability with the Columnstore database once
you have a good command of its UM/PM/GlusterFS architecture for data redundancy.
• A reactive and competent 24/7 remote DBA support team.
• A panel of very interesting tools around MariaDB (MONYog, SQLYog, Maria backup).
• A very attractive return on investment with a cost divided by more than three compared
to an equivalent Oracle solution.
32. 31
5. Assessment
Next steps with MariaDB ?
New projects with MariaDB to come like:
• Finalize the implementation of Maxcale in the transactional architecture
• The implementation of our own private key infrastructure with the database part under
MariaDB cluster.
A very important and strategic new feature for PIXID for its international development !
• A new migration of the Oracle database to MariaDB for our latest electronic signature tool
in collaboration with the solution's editor.
• The migration of all our Zmanda backups to MariaBackup