DronaBlog

Wednesday, July 24, 2024

What is Thread Contention?

 

Understanding Thread Contention

Thread contention occurs when multiple threads compete for the same resources, leading to conflicts and delays in execution. In a multi-threaded environment, threads often need to access shared resources such as memory, data structures, or I/O devices. When two or more threads try to access these resources simultaneously, contention arises, causing one or more threads to wait until the resource becomes available. This can lead to performance bottlenecks and decreased efficiency of the application.

How Thread Contention Works

To manage access to shared resources, mechanisms like locks, semaphores, and monitors are used. These synchronization mechanisms ensure that only one thread can access the resource at a time. However, excessive use of these mechanisms can lead to contention, where threads spend more time waiting for locks to be released than performing useful work.






Example of Thread Contention

Consider a scenario where multiple threads are updating a shared counter:


public class Counter {

    private int count = 0;


    public synchronized void increment() {

        count++;

    }


    public synchronized int getCount() {

        return count;

    }


    public static void main(String[] args) {

        Counter counter = new Counter();

        Runnable task = () -> {

            for (int i = 0; i < 1000; i++) {

                counter.increment();

            }

        };


        Thread thread1 = new Thread(task);

        Thread thread2 = new Thread(task);


        thread1.start();

        thread2.start();


        try {

            thread1.join();

            thread2.join();

        } catch (InterruptedException e) {

            e.printStackTrace();

        }


        System.out.println("Final count: " + counter.getCount());

    }

}

In this example, the increment method is synchronized, meaning only one thread can execute it at a time. While this ensures correct updates to the shared counter, it also introduces contention when multiple threads try to access the increment method simultaneously.





Real-Time Example of Thread Contention

One notable example of thread contention causing major issues is the early days of Twitter. As the platform rapidly gained popularity, the infrastructure struggled to handle the increasing load. One specific issue was the handling of user timeline updates.

The Twitter Fail Whale Incident

In the early days, Twitter used a single-threaded system to update user timelines. When a user posted a tweet, the system updated the timelines of all followers. As the user base grew, this process became extremely slow, leading to significant delays and failures in updating timelines.

The problem was exacerbated by thread contention. Multiple threads were trying to update the same data structures (user timelines) simultaneously, causing severe contention and bottlenecks. The system couldn't handle the load, leading to frequent downtime and the infamous "Fail Whale" error page.

Resolution

Twitter resolved this issue by moving to a more scalable, distributed architecture. They introduced a queuing system where tweets were processed asynchronously, reducing contention and allowing for parallel processing of timeline updates. Additionally, they optimized their data structures and algorithms to minimize lock contention.


Thread contention is a critical issue in multi-threaded applications, leading to performance bottlenecks and inefficiencies. Proper synchronization mechanisms and architectural changes can help mitigate contention and improve the performance and scalability of applications. The example of Twitter's early infrastructure challenges highlights the importance of addressing thread contention in high-traffic systems.

Saturday, July 20, 2024

How to perform Fuzzy Match in Python?

 The thefuzz library is a modern replacement for fuzzywuzzy. Here's the script in order to perform fuzzy match in Python using thefuzz:





Business use case:

Create a detailed Python script to perform fuzzy matching. We have a file containing data, and the user will provide a search string. The goal is to perform a fuzzy match of the search string against the content of the file. The Python script should include code for reading the file and implementing the fuzzy match logic.

A) Install thefuzz:

pip install thefuzz

pip install python-Levenshtein


B) Script for reading a file and fuzzy matching input against file content

import sys
from thefuzz import fuzz
from thefuzz import process

def read_file(file_path):
    """Reads the content of the file and returns it as a list of strings."""
    try:
        with open(file_path, 'r', encoding='utf-8') as file:
            content = file.readlines()
        return [line.strip() for line in content]
    except FileNotFoundError:
        print(f"File not found: {file_path}")
        sys.exit(1)

def fuzzy_match(content, search_string, threshold=80):
    """
    Performs fuzzy match on the content with the search string.
    
    Args:
        content (list): List of strings from the file.
        search_string (str): The string to search for.
        threshold (int): Minimum similarity ratio to consider a match.
    
    Returns:
        list: List of tuples with matching strings and their similarity ratios.
    """
    matches = process.extract(search_string, content, limit=None)
    return [match for match in matches if match[1] >= threshold]

def main():
    if len(sys.argv) < 3:
        print("Usage: python fuzzy_match.py <file_path> <search_string> [threshold]")
        sys.exit(1)

    file_path = sys.argv[1]
    search_string = sys.argv[2]
    threshold = int(sys.argv[3]) if len(sys.argv) > 3 else 80

    content = read_file(file_path)
    matches = fuzzy_match(content, search_string, threshold)

    if matches:
        print("Matches found:")
        for match in matches:
            print(f"String: {match[0]}, Similarity: {match[1]}")
    else:
        print("No matches found.")

if __name__ == "__main__":
    main()






C) How to Run the Script

  1. Save the script as fuzzy_match.py.
  2. Prepare a text file with the content you want to search in, let's say data.txt.
  3. Run the script from the command line: 
python fuzzy_match.py data.txt "search string" [threshold]


  • data.txt is the file containing your data.
  • "search string" is the string you want to fuzzy match.
  • [threshold] is an optional parameter specifying the minimum similarity ratio (default is 80).

  • D) Example Usage

    python fuzzy_match.py data.txt "example search string" 75

    This script will read data.txt, perform a fuzzy match with "example search string", and print the matches with a similarity ratio of at least 75.

    E) Explanation

  • read_file: This function reads the file content and returns it as a list of stripped strings.
  • fuzzy_match: This function performs fuzzy matching on the list of strings using the thefuzz library. It filters matches based on a similarity ratio threshold.
  • main: This is the entry point of the script. It checks for command-line arguments, reads the file content, performs the fuzzy match, and prints the results.

  • Friday, July 12, 2024

    What is ROWID_OBJECT and ORIG_ROWID_OBJECT in Informatica MDM and what is significance?

     In Informatica Master Data Management (MDM), ROWID_OBJECT and ORIG_ROWID_OBJECT are critical identifiers within the MDM data model, particularly within the context of data storage and entity resolution.





    ROWID_OBJECT

    • Definition: ROWID_OBJECT is a unique identifier assigned to each record in a base object table in Informatica MDM. It is automatically generated by the system and is used to uniquely identify each record in the MDM repository.
    • Significance:
      • Uniqueness: Ensures that each record can be uniquely identified within the MDM system.
      • Record Tracking: Facilitates tracking and managing records within the MDM system.
      • Entity Resolution: Plays a crucial role in the matching and merging processes. When records are matched and merged, the surviving record retains its ROWID_OBJECT, ensuring consistent tracking of the master record.




    ORIG_ROWID_OBJECT

    • Definition: ORIG_ROWID_OBJECT represents the original ROWID_OBJECT of a record before it was merged into another record. When records are consolidated or merged in the MDM process, the ORIG_ROWID_OBJECT helps in maintaining a reference to the original record's identifier.
    • Significance:
      • Audit Trail: Provides an audit trail by retaining the original identifier of records that have been merged. This is crucial for data lineage and historical tracking.
      • Reference Integrity: Ensures that even after records are merged, there is a way to trace back to the original records, which is important for understanding the data's history and origin.
      • Reconciliation: Aids in reconciling merged records with their original sources, making it easier to manage and understand the transformation and consolidation processes that the data has undergone.

    So, ROWID_OBJECT ensures each record in the MDM system is uniquely identifiable, while ORIG_ROWID_OBJECT maintains a link to the original record after merging, providing critical traceability and auditability in the MDM processes.


    Learn more about ROWID_OBJECT in Informatica MDM here -



    Thursday, July 11, 2024

    What are differences between Daemon thread and Orphan thread in java?

     In Java, the concepts of daemon threads and orphan threads refer to different aspects of thread management and behavior. Here's a detailed comparison:





    Daemon Thread

    • Purpose: Daemon threads are designed to provide background services while other non-daemon threads run. They are often used for tasks like garbage collection, background I/O, or other housekeeping activities.
    • Lifecycle: Daemon threads do not prevent the JVM from exiting. If all user (non-daemon) threads finish execution, the JVM will exit, and all daemon threads will be terminated, regardless of whether they have completed their tasks.
    • Creation: You can create a daemon thread by calling setDaemon(true) on a Thread object before starting it. Example:
      Example:
      Thread daemonThread = new Thread(new RunnableTask()); daemonThread.setDaemon(true); daemonThread.start();
    • Usage Consideration: Daemon threads should not be used for tasks that perform critical operations or that must be completed before the application exits.




    Orphan Thread

    • Definition: The term "orphan thread" is not a standard term in Java threading terminology. However, it generally refers to a thread that continues to run even though its parent thread (the thread that created it) has finished execution.
    • Lifecycle: Orphan threads are still considered user threads unless explicitly set as daemon threads. Therefore, they can prevent the JVM from shutting down if they are still running.
    • Creation: An orphan thread can be any thread that is created by a parent thread. If the parent thread completes its execution, but the child thread continues to run, the child thread becomes an orphan thread. Example:
      Example:
      Thread parentThread = new Thread(new Runnable() { @Override public void run() { Thread childThread = new Thread(new RunnableTask()); childThread.start(); // Parent thread finishes, but child thread continues } }); parentThread.start();
    • Usage Consideration: Orphan threads are normal user threads, so they need to be managed properly to ensure that they don't cause the application to hang by keeping the JVM alive indefinitely.

    Key Differences

    1. JVM Exit:
      • Daemon Thread: Does not prevent the JVM from exiting.
      • Orphan Thread: Can prevent the JVM from exiting if it is a user thread.
    2. Creation:
      • Daemon Thread: Explicitly created by setting setDaemon(true).
      • Orphan Thread: Any child thread that outlives its parent thread.
    3. Use Case:
      • Daemon Thread: Used for background tasks.
      • Orphan Thread: Can be any thread continuing to run independently of its parent thread.

    Understanding these concepts helps in designing multi-threaded applications where thread lifecycle management is crucial.

    Tuesday, July 9, 2024

    What is Landing table, Staging table and Base Object table in Informatica MDM?

     In Informatica Master Data Management (MDM), the concepts of landing tables, staging tables, and Base Object tables are integral to the data integration and management process. Here's an overview of each:





    1. Landing Table:

      • The landing table is the initial point where raw data from various source systems is loaded.
      • It acts as a temporary storage area where data is brought in without any transformations or validation.
      • The data in the landing table is usually in the same format as it was in the source system.
      • It allows for an easy inspection and validation of incoming data before it moves further in the ETL (Extract, Transform, Load) process.
    2. Staging Table:

      • The staging table is used for data processing, transformation, and validation.
      • Data is loaded from the landing table to the staging table, where it is cleaned, standardized, and prepared for loading into the Base Object table.
      • This step may involve deduplication, data quality checks, and application of business rules.
      • Staging tables ensure that only high-quality and standardized data proceeds to the Base Object table.
    3. Base Object Table:

      • The Base Object table is the core table in Informatica MDM where the consolidated and master version of the data is stored.
      • It represents the golden record or the single source of truth for a particular business entity (e.g., customer, product, supplier).
      • The data in the Base Object table is typically enriched and merged from multiple source systems, providing a complete and accurate view of the entity.
      • Base Object tables support further MDM functionalities such as match and merge, hierarchy management, and data governance.




    In summary, the flow of data in Informatica MDM typically follows this sequence: Landing Table → Staging Table → Base Object Table. This process ensures that raw data is transformed and validated before becoming part of the master data repository, thereby maintaining data integrity and quality.


    Learn more about Tables in Informatica Master Data Management here



    What is Fuzzy match and Exact match in Informatica MDM?

     In Informatica Master Data Management (MDM), matching strategies are crucial for identifying duplicate records and ensuring data accuracy. Two common matching techniques are fuzzy match and exact match. Here's a detailed explanation of both:

    Fuzzy Match

    Fuzzy matching is used to find records that are similar but not necessarily identical. It uses algorithms to identify variations in data that may be caused by typographical errors, misspellings, or different formats. Fuzzy matching is useful in scenarios where the data might not be consistent or where slight differences in records should still be considered as matches.

    Key Features of Fuzzy Match:

    1. Similarity Scoring: It assigns a score to pairs of records based on how similar they are. The score typically ranges from 0 (no similarity) to 1 (exact match).
    2. Tolerance for Errors: It can handle common variations like typos, abbreviations, and different naming conventions.
    3. Flexible Matching Rules: Allows the configuration of different thresholds and rules to determine what constitutes a match.
    4. Algorithms Used: Common algorithms include Levenshtein distance, Soundex, Metaphone, and Jaro-Winkler.




    Exact Match

    Exact matching, as the name suggests, is used to find records that are identical in specified fields. It requires that the values in the fields being compared are exactly the same, without any variation. Exact matching is used when precision is critical, and there is no room for errors or variations in the data.

    Key Features of Exact Match:

    1. Precision: Only matches records that are exactly the same in the specified fields.
    2. Simple Comparison: Typically involves direct comparison of field values.
    3. Fast Processing: Because it involves straightforward comparisons, it is generally faster than fuzzy matching.
    4. Use Cases: Suitable for fields where exactness is essential, such as IDs, account numbers, or any field with a strict, unique identifier.

    Use Cases in Informatica MDM

    • Fuzzy Match Use Cases:

      • Consolidating customer records where names might be spelled differently.
      • Matching addresses with slight variations in spelling or formatting.
      • Identifying potential duplicates in large datasets with inconsistent data entry.
    • Exact Match Use Cases:

      • Matching records based on unique identifiers like social security numbers, account numbers, or customer IDs.
      • Ensuring the integrity of data fields where precision is mandatory, such as product codes or serial numbers.




    Fuzzy Match Examples

    1. Names:

      • Record 1: John Smith
      • Record 2: Jon Smith
      • Record 3: Jhon Smyth

      In a fuzzy match, all three records could be considered similar enough to be matched, despite the slight variations in spelling.

    2. Addresses:

      • Record 1: 123 Main St.
      • Record 2: 123 Main Street
      • Record 3: 123 Main Strt

      Here, fuzzy matching would recognize these as the same address, even though the street suffix is spelled differently.

    3. Company Names:

      • Record 1: ABC Corporation
      • Record 2: A.B.C. Corp.
      • Record 3: ABC Corp

      Fuzzy matching algorithms can identify these as potential duplicates based on their similarity.

    Exact Match Examples

    1. Customer IDs:

      • Record 1: 123456
      • Record 2: 123456
      • Record 3: 654321

      Exact match would only match the first two records as they have the same customer ID.

    2. Email Addresses:

      Only the first two records would be considered a match in an exact match scenario.

    3. Phone Numbers:

      • Record 1: (123) 456-7890
      • Record 2: 123-456-7890
      • Record 3: 1234567890

      Depending on the system's configuration, exact match may only match records formatted exactly the same way.

    Mixed Scenario Example

    Consider a customer database where both fuzzy and exact matches are used for different fields:

    1. Record 1:

    2. Record 2:

    3. Record 3:

    In this case, using fuzzy match for the name field, all three records might be identified as potential matches. For the email field, only records 1 and 2 would match exactly, and for the phone field, depending on the normalization of phone numbers, all three might match.

    In summary, fuzzy matching is useful for finding records that are similar but not exactly the same, handling inconsistencies and variations in data, while exact matching is used for precise, identical matches in fields where accuracy is paramount.


    Learn more about Informatica MDM here



    What is Glue Job in AWS?

    An AWS Glue job is a managed ETL (Extract, Transform, Load) job used to process data in AWS. AWS Glue makes it easy to discover, prepare, an...